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ABSTRACT 


A  timeshared  microcomouter  monitor  for  Intel  b  0  6  0 
microprocessor  systems  development  has  been  described. 
Running  on  the  Sycor  440  Clustered  Terminal  Processina 
System*  the  monitor  provides  a  virtual  environment  comoosed 
of  a  console  device*  eight  floorv  disk  drives*  and  an  b  0  y  0 
m i c roorocessor  for  up  to  four  concurrent  users.  Virtual 
floppy  disk  files  on  a  five  meaabvte  movable-head  disk 
provide  the  system's  primary  auxiliary  storaoe  medium. 
Three  different  levels  of  access  protection  are  available 
for  these  virtual  flopoy  disk  images.  A  command  1  a  n  a  u  a  q  e 
processor  has  been  included  to  support  nn-line  modification 
of  the  virtual  environment.  System  recovery  in  the  event  of 
a  hardware  or  software  failure  is  also  supported  by  the 
mon  i  t or . 
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I.   INTRODUCTION 


A.   BACKGROUND 


In  the  summer  of  1976  the  Computer  Science  Department  at 
the  Naval  Postgraduate  School  (MPS)  acquired  a  Sycor  Model 
4  4  0  Clustered  Terminal  processinq  System  for  use  in  the  MPS 
microcomputer  laboratory.  The  Sycor  4  4  0  utilizes  an  Tntel 
8080  LSI  chip  as  the  CPU  of  a  special  purpose  microcomputer 
system  designed  primarily  for  data  entry  applications.  In 
addition  to  the  8080  CP",  the  440  hardware  configuration 
includes  a  five  meoabyte  movable-head  disk,  64K  of  random 
access  memory  (RAM),  a  cassette  tape  drive/  ana  four  di^plav 
terminals  consisting  of  a  keyboard  and  cathode  ray  tuoe 
(CRT)  display  device.  Two  peripheral  devices  are  also 
provided:  a  serial  printer  and  an  RS-P32  compatible 
asyncronous  communication  interface. 

As  part  of  the  Model  440  System,  Sycor,  Inc.  supplied  a 
comprehensive  package  of  system  software.  Most  of  this 
software  was  designed  to  support  applications  in  the  data 
entry  field  which  comprised  the  Sycor  440's  primary 
marketing  taraet.  In  addition  to  the  basic  data  entry 
packaae  Sycor  also  supplied  several  programs  which  exercise 
the  440's  capabilities  more  fully.  These  included  a 
resident  COBOL  compiler;  a  cross-compiler  for  PLMR,  a 
relocatable  version  of  the  system  development  lanauage  PL/M; 


and  a  1  i  n  k  i  n  q  loader  which  combines  relocatable  segments  of 
COBOL  or  PLMR  object  code  into  an  executable  object  module. 

Prior  to  the  arrival  of  the  Svcor  4  4  0,  the  facilities 
available  in  the  N  P  S  microcomputer  laboratory  consisted 
primarily  of  two  TNTELLEC  8  /  ^  0  D  80  microcomputer  systems 
designed  for  use  in  the  develoDment  of  software  for  the 
Intel  8080  chip  processors.  Both  of  these  systems  support 
the  C  P / M  (Control  Program  for  Microcomputers)  operatina 
system  [21.  CP/M  provides  many  software  development  tools 
including  a  context-  editor,  dynamic  debuaqer,  and  assembler 
for  the  generation  of  8080  object  code  f  3  -  6 1  .  However,  CP/M 
provides  only  a  single  display  terminal  interface,  ano  uses 
floppy  disks  as  its  auxiliary  storage  medium. 

While  the  Svcor  440  made  a  sianificant  and  welcome 
addition  to  the  hardware  complement  of  the  *IFS  m  i  c  rocomout  er 
laboratory,  a  great  deal  of  effort  was  required  to  intearate 
the  new  system  into  the  current  laboratory  configuration  and 
to  ensure  that  maximum  benefit  could  be  derived  from  the  new 
acguisition.  The  following  paraaraphs  summarize  the  goals 
and  objectives  of  this  effort. 

B.   GOALS  AND  OBJECTIVES 

The  primary  goal  of  the  Sycor  440  integration  effort  was 
to  complete  an  i nvest i aat i on  of  the  desian  and  architecture 
of  the  available  hardware  con f i qura t i on ,  and  the 
capabilities  of  the  exist inq  software  with  an  eye  towards 
the  most  feasible  use  of  the  Sycor  440  system  in  support   of 
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the  tutorial  and  research  activities  of  the  MPS 
microcomputer  laboratory.  It  was  felt  that  the  Sycor  440 
hardware  had  the  capability  to  support  numerous  applications 
more  generalized  than  the  data  entry  function  it  was 
designed  and  programmed  to  accomplish.  In  particular/  the 
cluster  of  four  terminals  suaoested  the  development  of  a 
timeshared  environment  to  support  uo  to  four  simultaneous 
users  on  a  single  Sycor  4  4  0.  Such  a  timeshared  system  would 
provide  an  effective  increase  from  two  to  six  8080  CPU's 
available  for  use  in  the  m i c rocomout e r  laboratory.  This 
increase  would  oo  a  lona  wav  towards  meet i no  the  increased 
demand  for  microcomputer  research  and  development 
f aci 1 i  t  i  tes  at  MPS. 

A  secondary  goal  of  the  440  integration  effort  was  to 
ensure  that  a  well-defined*  comoatihle  interface  was 
established  between  the  current  laooratorv  configuration  and 
the  newly  acqui  red  Sycor  system.  The  objective  here  was 
twofold:  first/  to  achieve  hardware  compatibility  between 
the  Sycor  440  and  other  computer  systems  available  in  the 
lab/  and  secondly  to  achieve  software  compatibility  between 
the  Sycor  440  and  other  systems  which  utilize  the  8080  CPU 
chip. 

Achieving  hardware  compatibility  depended  on  tailoring 
the  440's  asyncronous  communication  interface  to  the 
requirements  of  existing  systems/  oarticularlv  the  P  D  P  -  1  1  /"d  0 
which  served  as  the  central  interface  point  for  inter- 
processor  communication.  It  was  anticiDated  that  this 
hardware   interface   could   be   easilv   established   without 
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modification  of  the  Sycor  system. 

Achieving  software  compatibility  was  viewed  as  a  much 
more  difficult  objective.  This  would  involve  developing  an 
environment  which  could  support  software  that  had  already 
been  written  for  other  systems  utilizing  the  8080  CPU  chip. 
For  programs  develooed  at  NPS  this  meant  that  the  Svcor  440 
environment  must  supoort  a  suitably  modified  version  of 
CP/M. 

C.   PROBLEM  DEFTNTTTON 

The  thesis  oroject  which  eventually  evolved  from  the 
Svcor  440  integration  effort  was  development  of  the 
Microcomputer  Timeshared  System  ( M  T  S  )  ,  a  software  Tonifor 
for  the  Sycor  440  designed  to  support  microcomputer  svstem 
development.  The  possibility  of  orovidina  a  virtual  machine 
environment  was  invest iaated,  including  the  incorporation  of 
virtual  device  interfaces  where  practical.  The  Sycor  4  40 
file  svstem  was  to  be  utilized  where  possible  in  order  to 
reduce  development  timer  avoid  duplication  of  system 
facilities,  and  allow  the  Sycor  operating  system  to  be  used. 
The  man-machine  interface  at  the  terminals  was  to  be  simple, 
flexible,  convenient  and  incorporate  the  best  features  of 
existing  interactive  systems  at  NPS.  This  system  was  to 
provide  a  suitable  interface  for  user  proarams  and/or 
operating  systems  to  enable  utilization  of  the  Svcor  4  40 
storage  and  peripheral  devices  by  these  proarams. 

It  was  realized  from   the   project's   inception   that   a 
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microcomputer  timesharina  system  is  ideally  implemented 
through  multiprocessing  rather  than  multiproqrammino.  The 
use  of  LSI  technoloav  has  made  the  CPU  cost  only  a  minor 
factor  in  the  total  cost  of  a  microcomputer  system.  A  major 
objective  in  the  development  of  MTS  was  findinq  an 
efficient/  practical  method  of  sharing  hardware  resources 
other  than  the  CPU.  The  unit  costs  of  memory,  fixed  disks, 
printers,  terminals,  and  other  oerioherals  are  major  factors 
in  total  system  cost  -  the  sharina  of  these  resources  was 
the  primary  consideration. 

To  achieve  the  project  objectives,  a  survey  of 
timesharing  concepts  and  implementations  was  conducted. 
Particular  attention  was  devoted  t o  the  current  desian  and 
implementation  techniques  of  virtual  machine  timesharina 
systems  to  determine  those  features  which  could  be  included 
in  MTS.  This  research  included  studv  of  timesharing  s  v  s  f  e  ^ 
techniques  associated  with  processor  management,  memory 
management,  and  device  management.  Those  factors  which 
influenced  the  design  of  MTS  ar*  discussed  in  the  npxt 
chaoter . 
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II.   TIMESHARING  CONCEPTS 


The  concept  of  t  imesharinq  computer  system  resources  was 
first  demonstrated  in  the  early  1 9 6 0 ' s .  Since  that  rime* 
growth  in  the  application  of  timesharinq  concepts  to  many 
classes  of  system  operational  requirements  and  desiqns  has 
occurred  rapidly.  The  timesharinq  field  Has  matured  now  to 
the  point  that  one  can  recognize  many  common  design  ooals 
and  implementation  concepts  beinq  used  in  a  wide  variety  of 
systems.  General  characteristics  of  timesharing  systems, 
methods    of    i mn 1 ement at i on f  and    resource    management 

techniques   were   researched   in   order  to  ioentify  concents 
which  could  be  applied  to  a  microcomputer  timeshared  system. 

A.   CHARACTERISTICS  OF  TIMESHARING  SYSTEMS 

/ 

One  of  the  original  motivations  for  development  of  early 
timesharing  systems  was  to  obtain  more  efficient  use  of  a 
computer  system's  expensive  operating  time  and  resources 
than  was  beino  realized  through  batch  environments. 
Interactive  or  conversational  timesharinq  imposes  the 
additional  burden  of  teepino  the  "user"  busy*  as  well  as  *he 
hardware.  System  response  time  must  be  directlv 
prooort ional  to  the  user's  expectations.  Those  tasks  which 
the  user  perceives  as  si  mole  must  result  in  rapid  resoonse 
from   the   system.   Fcr   example,  character  echoing  or  inout 


14 


M^H^^^^^ 


line  e  d  i  t  i  n  q  might  be  expected  to  require  no  aporeciable 
delay.  On  the  other  hand/  the  user  would  expect  a  large 
program  assembly  or  comoilation  to  take  more  time  and 
therefore  some  delay  would  be  acceptable. 

Another  important  consideration  is  that  of  system 
protection.  The  independence  of  concurrently  executing 
processes  must  be  maintained.  Protection  of  the  system  from 
user  processes*  as  well  as  user  processes  from  each  other, 
must  be  considered.  Protection  of  system  resources  such  as 
the  file  system  and  I/O  devices  must  be  maintained.  System 
protection  mav  be  implemented  at  many  levels*  both  in 
hardware  and  software.  Within  the  software  system, 
protection  information  for  specific  resources  is  normally 
maintained  in  various  tables  associated  with  these  resources 
t 1 6 1 .  Hardware  mechanisms  can  be  provided  to  suoport  svstem 
protection.  For  example/  the  use  of  bound  registers  to  trao 
invalid  memory  references  could  be  implemented  [10].  The 
operating  system  can  be  insulated  from  the  user  processes  by 
providing  separate  system  states  fe.g.  system  and  user)  or 
other  lockout  mechanisms  to  identify  when  the  system  is 
executing  in  the  system  rather  than  the  user  state. 

Related  to  system  protection  are  the  important  concepts 
of  system  reliaoility  and  recove rab i 1 i t y .  The  user  exoects 
the  system  to  ooerate  reliably  and  if  a  failure  should 
occur,  to  recover  as  smoothly  and  rapidly  as  possible.  Thar 
is,  recovery  should  preserve  the  user  data  and  proarams 
which  were  not  related  to  the  failure.  The  goal  in 
designing  recovery  procedures  is  to  minimize  the   impact   of 
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the  recovery  mechanism  on  the  system  when  it  is  operating 
normally*  yet  ensure  smooth  and  raoid  recovery  shoulH  a 
f ai 1 ure  occur . 

B.   VIRTUAL  MACHINES 

In  recent  years*  the  multiolexinq  of  computer  system 
resources  has  been  accomplished  in  some  implementations  bv 
utilizing  the  Virtual  Machine  Monitor  (VMM)  concent.  A  VMM 
is  a  special  form  of  ooerating  svstem  that  multiplexes  onlv 
the  physical  resources  among  the  users  -  no  other  functional 
enhancements  are  providea  tlOl.  The  concept  is  to  produce 
the  effect  of  multiple  bare  machines  which  are  identical  to 
the  bare  machine  on  which  the  VMM  runs.  Thus,  each  user  can 
select  the  operating  system  of  his  choice  to  run  on  his 
"private"  computer. 

1.   Virtual  Devices 

Under  the  VMM  concent*  all  I/O  is  simulated.  when  a 
user  program  attempts  to  execute  an  I/O  instruction*  control 
is  tranferred  to  the  VMM  via  an  interrupt.  There  are 
normally  three  different  situations  which  may  arise: 

(1)  If  the  I/O  device  physically  exists  and  has  been 
assigned  to  that  user  program,  the  instruction  may  be 
executed  immediately  without  modification. 

(2)  If  a  similar  I/O  device  exists*  the  I/O  commands  are 
appropriately  modified  and  then  executed.  For 
example*  many  small  disks  may  be  simulated  by  using 
separate  areas  of  a  sinale  large  disk. 
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(3)  Certain  devices*  such  as  orinters  and  card  readers* 
may  be  extensively  simulated  using  techniques  such  as 
spoolinq  (see  Device  Management)  [10). 

2 .   Hardware  Requirements 

The  implementation  of  a  practical  virtual  machine 
monitor  requires  that  the  host  computer  have  certain 
hardware  characteristics: 

(1)  The  instruction  set  should  contain  both  privileoed  and 

non-pr i v i 1 eoed  instructions. 
(?)  The  host  computer  must  have  some  wav  of  distinguishing 
between  the  two  tyoes  of  instructions.  That-  i  s  »  the 
VMM  must  be  made  aware  of  any  attempt  by  a  user's 
prooram  to  execute  a  orivileoea  instruction*  or  change 
its  mode  of  ooeration.  This  is  normally  satisfied  f  >  v 
establishinq  two  separate  states  of  operation*  system 
and  user . 

(3)  The  VMM  must  be  protected  from  the  user  proorams*  i.e. 
the  memory  assioned  to  the  VMM  must  be  protected  in 
both  read  and  write  mode. 

(4)  The  user  programs  must  be  protected  or  isolated  from 
each  other.  This  means  that  memory  or  input/outout 
devices  assioned  to  one  user  nrogram  must  be 
inaccessible  from  any  other  user  proaram*  unless 
proDer  safeguards  are  provided.  Isolation  and 
protection  of  memorv  areas  can  be  accomolished  by  some 
form  of  memory  protection  or  an  address  translation 
scheme  [11]. 
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A  machine  which  satisfies  these  requirements  can  ensure  the 
degree  of  control  by  the  VMM  necessary  to  avoid  excessive 
overhead  in  the  translation  or  simulation  process. 

C.   PROCESSOR  MANAGEMENT 

The  task  of  processor  manaaement  in  the  mu 1 t i programm i na 
environment  of  a  timeshared  system  involves  the  scheduling 
and  managina  of  multiple  nrocesses  in  different  stages  of 
completion.  A  process  may  exist  in  one  of  three  states! 
(1)  running,  (2)  ready  to  execute*  or  (3)  blocked  oendinq 
the  comoletion  of  I '0  or  some  other  process. 

A  process  is  in  the  running  state  if  it  is  executino 
instructions.  The  ready  to  execute  (ready!  state  describes 
a  process  that  is  ready  for  execution  but  not  currently 
running  due  to  the  unavailability  of  the  CPU.  A  blocked 
process  is  one  which  cannot  run  until  some  signal  arrives  to 
unblock  it.  These  unblocking  signals  are  referred  to  as 
"wake-up"  signals  and  change  the  status  of  a  process  from 
blocked  to  the  ready  state.  Such  signals  can  come  from  many 
sources:  system  orocesses,  user  processes,  hardware 
interrupts,  such  as  terminal  communications  equipment,  a 
timer,  or  completion  of  a  disk  I/O  operation  [16], 

Since  there  is  no  guarantee  that  a  process  will  block 
itself,  timesharing  systems  must  provide  a  mechanism  for 
regaining  control  of  the  CPU  from  the  currently  r  u  n  n  i  n  a 
process  in  order  to  provide  all  users  with  adequate  response 
times.   The  length  of  time  which  a  process  is  allowed  to  run 
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before  it  is  blocked  is  called  a  quantum  or  a  timeslice. 
The  quantum  size  is  one  of  the  most-  important  parameters  of 
a  schedulina  algorithm.  It  mav  be  fixed  or  variable/ 
depending  on  other  parameters  such  as  process  size/  process 
priority/  or  length  of  time  the  process  last  ran.  Settinq 
quantum  lengths  is  a  function  of  the  system  characteristics 
and  workload/  and  can  be  determined  only  Hy  experiment  with 
the  actual  system  or  by  simulation  tl6], 

D.   MEMORY  MANAGEMENT 

Memory  manaqement  involves  t^e  memory  allocation  and 
swaopinq  functions.  This  includes  k  e  e  p  i  n  a  track  of  the 
virtual  memory  space  of  each  process  in  the  svstemf  whether 
it  is  in  main  memory*  auxiliary  storaqe/  or  both.  The 
complexity  of  this  task  may  ranqe  from  maintainina 
relatively  few  tables  in  support  of  a  single  contiouous 
allocation  scheme/  to  the  maintaining  of  ^any  memorv 
allocation  data  structures  to  support  a  virtual  memory 
implementation  using  de^and-paa i no  or  segmented  memory 
management  schemes  [10,16]* 

Swaopinq  can  be  defined  as  moving  processes  between  main 
memory  and  auxiliary  storaoe  in  order  to  multiplex  main 
memory.  Swapping  time  is  the  time  it  takes  to  complete  a 
swapping  task.  The  mul t i proaramm i nq  of  processes  in  a 
timeshared  system  results  in  the  swaopinq  time  having  a 
major  impact  on  the  system's  response  time.  There  are  two 
important  parameters  of  an   auxiliary   storage   device   that 
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affect  swapping  times: 

(1)  The  averaoe  length  of  time  required  to  access  the 
required  block  of  information.  This  is  called  the 
averaoe  access  time. 

(2)  The  time  required  to  transfer  the  block  to  and  from 
main  memory.  This  is  inversely  proportional  to  the 
t  ransf er  rat  e  116]. 

Early  timesharing  systems  such  as  the  Compatible 
Timesharing  System  fCTSS)  used  very  simple  allocation  and 
swaoping  strategies  [101.  Mo  attemnt  was  made  to  overlao 
the  execution  of  one  orocess  with  the  swappinc  of  another. 
Only  one  complete  process  resided  in  memory  at  once  and  all 
processes  were  loaded  relative  to  a  constant  fixed  location. 
That  iSf  no  dynamic  relocation  was  used  because  no  dynamic 
relocation  hardware  was  available  on  these  earlv  systems. 

E.   DEVICE  MANAGEMENT 

Device  manaoement  involves  keepinq  track  of  the  aevicp 
resources/  allocatinc  the  device  resources  to  a  process; 
initiatinq  the  I/O  operation  and  reclaiming  the  resource  (in 
most  cases  the  I/O  terminates  automatically).  Devices  fall 
into  two  general  cateoories: 

(1)  Dedicated  -  those  devices  which  are  most  efficiently 
assigned  to  one  user  for  a  oiven  t-ime  period/  even 
though  the  user  may  not  be  able  to  utilize  the  device 
continuously.  In  this  category  are  tape  drives* 
printers*  and  card  eguioment. 
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( 2 )  Sharable  -  those  devices  which,  while  allowing   access 

to   only   one   crocess  at  a  time*  can  rapidly  comolete 

their  service  for  individual  processes  and  be   quickly 

switched   to   service  requests  of  other  processes.   In 

this  cateqory  are  such  online  auxiliary  storaqe   units 

as  drums,  disks,  and  data  cells  [161. 

The  ooeration  of  some  dedicated  devices  may  be  simulated 

to   provide   more  flexibility  and  improved  responsiveness  to 

user  reauests.  For  example,  the  operation  of  printinq  a  file 

on   the   printer   could  be  transformed  into  a  "  w  r  i  t  p "  onto  a 

disk  (a  virtual  printer)  where  at  some  later  time   a   second 

routine   would  cooy  the  information  onto  the  actual  printer. 

This  process  is  called  sooolinq,  and   allows   (1)   dedicated 

devices   to  be  shared,  hence,  more  flexibility  in  scheduling 

these  devices?  (.2)     more  flexibility  in  Job   schedulinq;   and 

(3)   improved  synchronization  of  the  speed  of  the  device  and 

the  arrival  rate  of  requests  for  that  device  (101. 
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III.   SYCOR  440  HARDWARE  DESCRIPTION 


The  Sycor  440  Clustered  Terminal  Processino  System  at 
NPS  is  composed  of  a  control  unit  containina  a  cassette  tape 
drive*  four  display  terminals*  a  Centronix  serial  printer* 
and  a  Sycor  Model  340  Communications  Terminal. 

The  control  unit  is  the  heart  of  th°  440  system. 
Contained  within  a  wais^-hiah  cabinet  are  random  and  control 
logic  including  two  8080  chips*  6  4  K  of  ranaom  access  memorv 
(RAM),  interfaces  for  all  oerioheral  devices*  a  fiv* 
megabyte  disk*  as  well  as  the  cassette  taoe  drive. 

One  of  the  two  80^0  chins  located  in  the  440  control 
unit  serves  as  the  system  CPU.  The  8080  instruction  set 
consists  of  78  data  transfer*  arithmetic*  loaical*  branch* 
stack*  I/O*  and  machine  control  instructions  [81.  Tne  Sycor 
440  provides  a  comprehensive  set  of  oriorit-ized  interrupts 
including  a  timer*  peripheral  device*  and  auxiliary  storage 
device  interrupts.  Control  information  and  data  are  passed 
between  the  8080  CPU  and  peripheral  devices  through  the  I/O 
ports  (referred  to  as  latches  in  Sycor  literature)  provided 
on  the  8080  chiD. 

The  second  8080  chiD  found  in  the  control  unit  acts  as  a 
controller  for  the  mini-disk.  The  mini-disk  is  a  sinole 
platter*  movable  head  disk  blocked  into  512  bvte  sectors. 
There  are  800  tracks  on  the  disk  with  13  sectors  per  track. 
Data  transfer  between  RAM  and  the  mini-disk   is   via   direct 


22 


memory  access  (DMA).  The  mini-disk  controller  communicates 
with  the  host  8080  CPU  through  a  13  byte  disk  control  block 
(DCB)  located  at  a  fixed  location  in  memory. 

Peripherals  supoorted  bv  the  Sycor  440  system  include 
synchronous  and  asynchronous  communication  devices*  up  to 
eight  disDlay  terminals*  serial  and  line  or  inters*  and  card 
readers.  The  NPS  configuration  has  four  display  terminals 
consisting  of  a  typewriter-like  keyboard  and  CRT  display 
device.  Each  terminal  displays  a  DMA  image  of  a  57b  byte 
terminal  buffer  located  in  RAM.  Keyboard  input  is 
accomplished  bv  software  translation  of  a  keyboard  matrix 
code  into  the  co r resDond i no  ASCII  character  code.  For 
hardcopy  output  the  NPS  440  includes  a  Centronix  serial 
matrix  orinter. 

Several  different"  auxiliary  storage  devices  ^av  be 
attached  to  the  Sycor  440  in  addition  to  the  mini-disK. 
These  include  magnetic  taoe  drives*  cassette  taoe  drives* 
and  floppy  disk  drives.  The  NPS  con f i aurat i on  includes  a 
cassette  taoe  drive  located  in  the  control  unit.  This  drive 
provides  compatibility  between  the  Sycor  440  svstem  and  the 
Model  340  debugaer. 

The  Model  340  Communications  Terminal  is  a  complete 
system  in  its  own  right  which  is  marketed  by  Sycor  for 
remote  job  entry  (RJE)  apolications  1131.  When  utilized  as 
a  hardware  debuager*  the  340  is  augmented  with  4K  of  PAW  and 
a  backplane  couolina  to  a  special  interface  board  in  the  440 
control  unit.  The  340  debugaer  is  provided  with  a  software 
package  which  includes  provisions  for   loadinq   ana   dumpina 


23 


hex  format  program  files  between  cassette  tape  and  4  4  0  RAN', 
examination  and  modification  of  individual  locations  in  4  4  0 
memory/  insertino  breakpoints  and  traps  in  proarams 
executing  on  the  440,  and  sinqle-steopina  through  a  rrogram 
executing  one  instruction  at  a  time  [151. 

There  are  several  hardware  characteristics  of  the  Sycor 
440  system  which  strongly  influenced  the  i mo  1 ement at i on  of 
MTS.   The  most  imoortant  of  these  arel 

(1)  8080  CPU  architecture 

(2)  terminal  design 

(3)  mini-disk  interface 

(4)  sinolp-state  CPU 

(5)  lack  of  memory  crotection 

The  impact  which  each  characteristic  had  on  the  desion  and 
implementation  of  MTS  is  covered  in  chaDters  IV  and  V.  For 
a  more  detailed  discussion  of  Svcor  440  hardware 
characteristics  see  Ref.  1. 
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IV.   MTS  DESIGN 


MTS  was  developed  in  order  to  integrate  the  Sycor  440 
into  the  tutorial  and  research  activities  at  MPS.  The 
original  problem  definition  given  in  section  I.C  provided 
general  guidelines  for  accomplishing  this  objective. 
Restated  briefly/  they  were: 

(1)  MTS  was  to  suoport  a  suitably  modified  version  of  C  P  /  w 

in    order   to   provide   compatibility   with   exist inq 

software  develooment  facilities. 

(?)  MTS  was  to  utilize  features   of   the   Sycor   operating 

svstem,    notably   the   Sycor   file   system?   wherever* 

possible  in  order  to  reduce   develooment   timer   avoid 

duplication    of    facilities*   and   allow   t^e   Sycor 

operating  svstem  to  be  used. 

(3)  MTS  was  to  provide   a   man-machine   interface   at   the 

terminals   which  was  simple*  flexible*  convenient*  and 

incorporated  the  best  features  of  exist ina  interactive 

systems  at  NPS. 

The  functions  performed  by  an  oneraMng   system   may   be 

divided    into    the   four   major   categories   of   processor 

management*  memory  management*  file  management-*   and   device 

management   [101.    The   aeneral   auidelines  mentioned  above 

effectively  eliminated  file  management  from  consideration  in 

the   design  of  yTS.   At  the  same  time*  the  selection  of  C  P  /  M 

as  the  operating  system  hosted  by  MTS  provided   a   familiar/ 
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well-defined  model  to  use   in   determininq   the   operational 
requirements  of  the  system. 

The  followinq  oaraqraphs  describe  the  final  design 
adopted  for  the  Microcomputer  Timeshared  Svstem  from  four 
different  points  of  view  corresoondina  to  the  four  major 
interfaces  which  can  be  identified  between  MTS  and  its 
operating  environment.  The  internal  view  covers  the 
functional  components  of  the  system  and  their 
i  nt  e  rdeoendenc  i  es .  The  external  view  deals  with  the 
relationship  between  V  T  S  and  the  Svcor  4  4  0  ooeratinq  system. 
The  MTS  environment  as  seen  by  a  user  oroaram  is  described 
in  the  user  program  view.  The  last  of  the  four,  terminal 
user  view,  describes  the  interface  between  a  terminal  user 
and  ^TS,  and  the  command  processor  which  oridges  this 
interface. 

A.   INTERNAL  VIEW 

1  .   VMM  Concept 

MTS  was  orioinallv  envisioned  as  a  software 
interface  between  the  bare  Sycor  440  machine  and  up  to  four 
user  tasks  executing  concurrently.  In  order  to  maintain 
compatibility  between  the  Sycor  440/^TS  system  and  existing 
NPS  microcomputer  development  facilities,  each  user  task 
would  be  provided  with  an  ooeratinq  environment  identical  to 
that  found  on  the  INTELLEC  A/MOD  «0  system. 

It  was  recoanized  that  the  Virtual  Machine  Moni tor 
concept   provided   the   simplest   and   most  eleoant  means  o* 
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implementing  such  a  software  interface.  A  oroperly  designed 
VMM  could  utilize  the  mini-disk  included  in  the  Sycor  440 
hardware  configuration  to  simulate  the  operation  of  multiple 
floppy  disk  drives  and  provide  each  user  with  a  dedicated 
virtual  printer  through  soooling.  Since  the  INTELLEC  8  and 
Svcor  440  microprocessors  are  both  based  on  the  Intel  8080 
CPU  chip,  the  machine  language  instruction  sets  of  the  two 
are  identical  and  interpretive  execution  would  not  be 
necessary.  The  virtual  operating  environment  viewed  by  a 
user  task  would  be  the  same  as  that  found  on  the  INTELLEC 
8/MOD  80.  Additionally/  the  monitor  itself  woula  be 
invisible  to  the  user. 

While  the  VMM  concept  provided  the  ideal  s  o  1  u  M  o  n  in 
theory/  there  were  several  hardware  limitations  which 
precluded  its  implement  ion.  The  discussion  of  the  VMM 
concept  in  chapter  TI  lists  four  hardware  characteristics  of 
the  host  computer  necessary  to  implement  a  practical  virtual 
machine  monitor.  These  four  characteristics  are  essential 
in  providinq  the  reliability/  inteoritv/  and  protection 
required  in  a  timesharinq  system.  Unfortunately/  the  Intel 
8080  chip  processors  satisfy  none  of  these  requirements. 
The  8080  is  a  single  state  CPU.  No  distinction  exists 
between  system  and  user  modes  of  operation;  consequently, 
there  is  no  need  to  orovide  both  privileaed  and  non- 
privileqed  instructions  in  the  machine's  instruction  set. 
This  makes  it  impossible  on  the  80*0  to  trap  I/n 
instructions  executed  by  a  user  task/  and  means  that  ail  I/O 
devices   are  accessible  to  whichever  task  currently  controls 
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the  CPU. 

A  more  serious  problem  is  the  lack  of  mpmorv 
protection.  The  80P0  provides  neither  bound  reaisters  nor 
address  translation  hardware  to  detect  memorv  references 
outside  the  user  task's  address  space.  This  shortcominn  not 
only  made  the  VMM  concent  impractical/  but  had  a  noticeable 
impact  on  the  design  finally  adopted. 

PerhaDS  the  stronnest  argumenr  for  usinq  the  VMM 
concept  in  implementing  a  timesharing  system  is  the 
transparency  of  the  V  w  M  '  s  oneraMon  to  user  tasks.  Since 
each  user  task  is  effectively  running  on  an  independent  bare 
machine*  the  VMM  imposes  no  restrictions  on  the  user  beyond 
those  imposed  bv  the  machine's  architecture.  It  was  fo-und 
necessary  in  the  desian  of  MTS  to  compensate  for  the 
limitations  of  the  8080  CPU  bv  imposing  certain  restrictions 
on  the  freedom  of  user  tasks. 

2.   MTS  Monitor  Concept 

MTS  was  designed  to  provide  a  timeshared,  virtual 
8080  mi c roorocessor  environment  for  microcomputer  systems 
development.  The  term  "virtual"  is  appropriate  here  because 
the  user  actually  interfaces  with  MTS  for  many  services 
normally  provided  by  the  hardware  in  a  dedicated  CPU 
environment.  A  software  interface  between  user  oroarams  and 
the  Sycor  440  hardware  was  necessary  in  order  to  allocate 
the  hardware  resources  eguitablv  and  efficiently/  while  at 
the  same  time  satisfyina  the  service  reauirements  of  several 
competing  user  tasks. 
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The  design  of  the  MTS  interface  drew  heavily  on  the 
VMM  concept.  MTS  was  desiqned  to  multiplex  only  the 
physical  resources  of  the  Svcor  440  system,  i.e.  memory,  the 
CPU,  auxiliary  storaqe  on  the  mini-dis^,  terminals*  and 
other  peripheral  I/O  devices.  No  attempt  was  made  to  orovide 
additional  functional  enhancements  such  as  a  file  system  or 
software  development  tools.  As  stated  in  the  aeneral 
guidelines  for  the  project/  it  was  expected  that  MTS  would 
supDort  a  suitably  modified  version  of  the  CP/M  operating 
system,  makino  such  enhancements  redunaant. 

The  NPS  Sycor  4  4  0  hardware  configuration  did  not 
include  floppy  disk  as  an  auxiliary  storaae  medium.  Since 
floppy  disks  are  provided  bv  the  INTELLFC  8/MOD  bO  systems, 
and  are  necessary  to  run  CP/M,  it  was  decided  to  implement 
virtual  floDDv  disks  and  disk  drives.  Provisions  were  also 
made  to  expand  the  system  to  include  virtual  printers/  card 
readers,  oaoer-taoe  readers,  and  other  dedicated  T/0  devices 
at  a  later  date . 

As  a  timesharina  system,  M  T  S  is  characterized  by  the 
following  major  features: 

(1)  the  use  of  swapping  to  implement  mu 1 t i p roaramm i ng 

(2)  the  use  of  interrupt  driven  processor  management  based 
on  a  round-robin  scheduling  algorithm 

(3)  the   use   of   virtual   floppy   disks   as   the   orimarv 
auxiliary  storaae  medium 

(4)  the  sharing   of   a   single   dedicated   I/O   device   bv 
multiple  users . 

Each  of  these  characteristics  is  discussed  in  detail  in  tMs 
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and  the  following  chapter. 

3.   Memory  Management 

The  Sycor  440  provides  64K  bytes  of  random  access 
memory.  Slightly  over  3K  bytes  of  this  is  requi  red  for 
terminal  and  cassette  DMA  buffers,  a  ROM  bootstrap  p  r  o  a  r  a  m  , 
a  mini-disk  control  block*  and  interrupt  processing.  Thp 
decision  was  made  that  a  minimum  of  4  P  K  contiouous  bytes  of 
memory  would  be  made  available  to  user  tasks  with  the 
remaining  13K  bytes  reserved  for  the  resiaent  portions  of 
MTS.  This  estimate  of  the  amount  of  memory  reauired  bv  WT5 
was  based  in  part  on  the  size  of  the  CP/M  operating  svstem 
and  was  intentionally  oenerous  to  provide  sufficient  memory 
for  future  growth  and  enhancement  of  MTS  facilities. 

Once  a  decision  had  been  made  on  the  amount  of 
memory  available  to  user  tasks  it  was  necessary  t- o  select 
the  optimum  method  of  manaaing  this  memory  space.  This 
decision  also  was  stromal v  influenced  by  hardware 
considerations.  The  Intel  R  0  fl  0  CPU  provides  only  a  sinole 
direct  addressinq  mode.  Since  the  Sycor  4  4  0  provides  no 
address  translation  hardware*  the  more  advanced  memory 
management  techniques  such  as  paginq  and  dynamic 
partitionino  were  infeasible.  The  only  practical  choices 
seemed  to  be  swapping  or  a  static  partitioninq  scheme. 

The  static  partition  approach  was  considered 
carefully  since  it  offered  several  advantages  over  swapping. 
Most  importantly/  a  memory  management  technique  which  ones 
not   involve   data   transfers   between   memory  and  auxiliary 
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storage  would  be  much  faster  than  swapping.  Static 
partitioninq  offered  the  added  advantage  of  simplicity. 
With  all  user  proarams  resident  in  memory  it  would  not"  d  e 
necessary  to  maintain  tables  showinq  the  disk  addresses  of 
blocked  or  ready  tasks. 

There  was  a  single  overriding  factor  which 
ultimately  mandated  the  selection  of  swapping.  & 
timesharing  system  must  maintain  the  integrity  of  all 
concurrently  executing  tasks.  Since  the  Sycor  440  provides 
no  memory  protection,  this  would  be  impossible  if  two  or 
more  tasks  were  resident  in  memory  simultaneously.  Not  only 
would  it  be  impossible  to  orevent  one  task  from  accessina 
another,  it  would  be  impossible  to  detect  the  occurrence  o f 
a  reference  out  of  bounds. 

The  use  of  swapoinq  provides  physical  as  well  as 
logical  separation  of  all  user  tasks  in  the  system. 
Associated  with  each  of  the  four  terminals  is  a  mini-disk 
file  used  to  store  a  memory  imaae  of  that  terminal's  current 
task  when  it  is  waiting  for  the  CPU  or  blocked  oendina  some 
I/O  operation.  At  any  given  instant  a  task  may  reside  on 
the  mini-disk  in  its  swap  file  or  in  memory,  but  at  no  time 
can  two  or  more  tasks  be  resident  in  memory  s i mu 1 t aneous 1 v . 

Swaoping  also  makes  available  to  each  task  tne 
entire  48K  user  area  of  memory  as  originally  planned.  tuen 
though  few  users  will  ever  write  a  sinale  proaram  which 
requires  the  entire  48k  bytes,  the  adoitiooal  memory  does 
enhance  the  operation  of  CP/M  development  tools  such  as  the 
text   editor   by   allowing   larger   Duffers   and   fewer  disk 
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accesses . 

While  the  incorporation  of  swaopinq  into  MTS  did 
solve  the  problem  of  maintaininq  task  integrity?  it  also  had 
the  undesirable  side  effect  of  m  a  k  i  n  a  the  mini-disk  a  a  t  a 
transfer  rate  the  limiting  factor  in  system  responsiveness. 
Based  on  informal  timinq  fiaures  provided  bv  Sycor»  it  was 
estimated  that  as  long  as  six  seconds  may  be  required 
between  timeslices  to  handle  the  swapping  of  two  4  6K  hvte 
tasks.  This  problem  was  recoonizel  earl v  in  the  Gpsian 
phase  of  development  and  solutions  were  sought  in  several 
areas.  A  partial  solution  to  the  problem  is  offered  by  an 
improved  mini-disk  controller  under  development  at  Sycor  as 
this  was  written.  Preliminary  tests  have  shown  that  tMs 
improved  controller  will  improve  the  mini-disk  transfer  rate 
by  a  factor  of  from  three  and  one-half  to  four  over  its 
present  value. 

Several  features  have  been  included  in  the  ^  T  S 
design  to  minimize  the  delay  inherent  in  swappino.  For 
example/  the  system  default  size  was  limited  to  16K  bvtes  in 
an  effort  to  reduce  the  size  of  the  memory  image  which  must 
be  transferred  to  the  mini-disk.  A  user  can  soecify  a 
larger  memory  size  if  required/  but/  in  the  absence  of  an 
explicit  reauest  for  more  memory/  16K  bytes  is  assumed. 
Consideration  was  also  given  to  minimizing  the  freouency  of 
memory  image  transfers.  The  scheduler  was  desioned  to  de*er 
swapping  until  it  oetermined  that  a  different  memory  image 
was  required  to  continue  orocessinq.  As  an  illustration, 
consider  the  case  of  a  sinqle  task  active  on  the  system.   If 
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swapping  is  not  deferred,  this  single  task  will  constantly 
thrash  back  and  forth  between  memory  and  the  mini-disk.  Bv 
deferring  each  swap  until  it  is  absolutely  necessary*  the 
overhead  due  to  swaopino  becomes  roughly  proportional  to  the 
number  of    active  tasks  minus  one,  or  zero     for    a  single  task. 

4 .   Processor  Management 

An  assumption  basic  to  the  entire  f^TS  development 
effort  was  that  MTS  would  support  m i c rocomou t er  systems 
development.  This  assumption  implies  tha*"  at  any  one  time 
some  of  the  tasks  active  on  the  system  may  renuirp 
relatively  large  amounts  of  CPU  time  while  others  may  be 
blocked  oendina  terminal  I/O.  In  order  to  ensure  that  the 
CPU  resource  is  allocated  fairlv  to  all  active  tasks  it  was 
decided  to  implement  an  interrupt  driven  task  scheduler. 
Each  task  is  allocated  the  CPU  for  a  fixed  interval  of  time 
called  a  timeslice.  A  task  retains  control  of  the  CPU  until 
a  haraware  timer  generates  an  interrupt  signaling  the 
expiration  of  the  task's  timeslice.  The  timer  interrupt 
handler  then  transfers  control  to  the  task  scheduler  to 
select  a  new  task  for  execution. 

Notice  that  interrupt  processing  is  carried  out 
independently  of  task  scheduling.  This  could  cause  a 
problem  if  a  timer  interrupt  should  occur  while  system  code 
is  oeing  executed.  The  task  currently  resiaina  in  memory 
would  be  swapped  out  reaardless  of  its  status.  This  problem 
was  resolved  by  desianino  MTS  to  set  a  software  lock  each 
time  it  is  entered.   The  timer  interrupt  handler  checks  this 
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lock  whenever  a  timeslice  expires   and   suppresses   swanpinn 
until  the  lockout  condition  has  been  cleared. 

5.   Virtual  FIoppv  Disks 

The  MTS  virtual  floppy  disk  drive  provides  auxiliary 
storage  for  user  proarams  on  virtual  floppy  disks.  These 
simulated  hard-sectored  disks  have  128  bytes  per  sector,  26 
sectors  per  track,  and  a  maximum  number  of  tracks  determined 
by  the  size  of  the  mini-disk  file  containino  the  disk  i  m  a  a  e  . 
Each  user  has  eight  drives  available  for  dedicated  use. 

A  virtual  floppy  disk  resides  on  a  block  of 
logically  contiguous  mini-disk  sectors.  Where  a  physical 
floppy  disk  has  a  fixed  capacity  of  2  5  6  K  bytes,  an  MTS 
virtual  disk  may  have  any  convenient  size.  MTS  assumes  that 
the  disk  image  is  made  up  of  contiguous  12  8  bvte  floppy  disk 
sectors  starting  with  track  0  sector  1,  proceed  incj  through 
the  26  sectors  of  track  0  to  track  1  sector  1,  and  so  on 
until  the  virtual  disk  file  is  full. 

In  order  to  access  a  virtual  floppy  disk  a  user 
program  must  provide  MTS  with  a  complete  sector  address  and 
the  base  address  of  a  128  byte  DMA  buffer  in  the  user's 
memory  space.  This  buffer  derives  its  name  from  the  nature 
of  the  data  transfer  operation:  to  the  user  program  it 
aopears  that  data  is  transferred  between  his  program  and  the 
virtual  floppy  disk  by  direct  memory  access. 

A  complete  sector  address  consists  of  a  virtual 
drive  number  and  the  virtual  disk  sector  and  track  numbers. 
With  this  information  MTS  can  calculate  the   offset   of   the 
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addressed  sector  in  the  mini-disk  file/  validate  that  the 
addressed  sector  is  within  the  file?  and  read  the  mini-disk 
sector  into  memory  for  transfer  of  the  specified  128  bytes 
to  the  user's  DMA  buffer. 

The  mapping  function  used  to  convert  a  complete 
sector  address  into  a  mini-disk  sector  number  is  based  on 
two  f ac  t  s : 

(1)  The  virtual  floppy  disk  imaoe  is  stored  as  a  linear 
array  with  the  sector  number  increasing  most  raoidlv 
and  the  track  number  increasing  least  rapidly. 

( 2 )  The  mini-disk  file  containing  the  virtual  disk  image 
is  a  single  contiauous  block  of  512  bvte  sectors. 

Recognizing  that  the  virtual  disk  imaae  is  stored  as  a 
linear  array,  the  offset  of  any  virtual  disk  sector  in  the 
file  becomes 

vs. offset  =  (?6  *  track. nr)  t  sector. nr. 
Applying  the  fact  that  each  512  byte   mini-disk   sector   may 
contain   up   to   four   virtual  floppy  disk  sectors,  the  file 
offset  and  position  of  the  specified  virtual  disk  sector   in 
the  mini-disk  buffer  can  now  be  calculated. 

file. offset  =  vs. offset  DIV  4 

buf.pos  =  (vs. offset  REM  4)  *  128 
where  DIV  and  REM  represent  integer  division  and  remainder 
respectivelv.  Once  the  file  offset  is  known,  it  is  a  si  mole 
matter  to  add  this  value  to  the  file's  base  sector  number  to 
complete  the  maopino.  Similarly,  the  buffer  position  is 
added  to  the  mini-disk  buffer's  base  address  to  find  the 
current  memory  address  of  the  specified  virtual  disk  sector. 
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B.   PROTECTION  AND  RECOVERY 

Thus  far  in  the  discussion  of  MTS  design  features  the 
topic  of  protection  has  already  been  encountered  several 
times.  It  has  been  stated  that  the  indenenaence  of 
concurrently  executing  processes  must  be  maintained*  and 
that  orotection  is  also  necessary  for  the  operating  svstem 
itself.  Due  to  the  architecture  of  the  S y c o r  'J  4  0  system,  a 
great  deal  of  consideration  was  given  to  the  protection 
problem  as  well  as  the  related  tonics  of  recovery  and 
privacy. 

1  .   System 

MTS  maintains  the  independence  of  concurrently 
executing  usei*  tasks  by  enforcina  Dhysica'  separation 
through  swaooing.  This  technigue  is  Dract ical  and 
effective*  but  only  deals  with  part  of  the  protection 
problem.  It  is  even  more  important  that  M  T  S  itself  be 
protected  from  user  tasks.  Situations  in  which  a  user  task 
may  inadvertently  overlay  or  modify  pieces  of  svstem  code 
must  be  avoided.  At  best  this  could  lead  to  a  system  crash 
with  varying  dearees  of  imoact  on  all  system  users;  at 
worst/  MTS  could  continue  processina  in  an  erratic  fashion 
which  causes  irrecoverable  damaoe  to  user  files.  The  first 
situation  is  immediately  obvious  to  the  system  users?  the 
second  may  go  undetected  for  just  lona  enough  to  be 
cat ast roph  i  c . 

The  technigue  used  to  protect  user  tasks  from  one 
another   cannot  be  apDlied  to  this  new  problem.   While  it  is 
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feasible  to  make  some  sections  of  the  system  such  as  the 
task  scheduler  or  terminal  command  processor  non-resident 
and  swap  them  in  as  required,  there  are  other  system 
functions  such  as  interrupt  handlers  which  must  he  resident 
at  all  times.  One  Dossible  solution  to  the  problem  would  be 
storing  all  system  code  in  read  only  memory  with  backup 
copies  of  all  system  data  maintained  on  the  mini -disk.  The 
simplicity  of  this  accroach  makes  it  3Dreal inn;  but 
nevertheless  impractical  for  reasons  discussed  in  the 
external  view  of  M T S  presented  in  section  IV.C.l. 

After  a  great  deal  of  consideration*  no  practical, 
effective  method  of  orovidinn  system  protection  could  be 
found  which  did  not  involve  imposing  an  unacceptable  amount 
of  protection  overhead  en  the  system.  Tn  lieu  of  a 
protection  scheme  if  was  decided  to  incorporate  a  recovery 
capability  into  the  MTS  design.  If  was  felt  that  the 
ability  to  recover  aracefully  from  occasional  inadvertent- 
system  crashes  would  compensate  somewhat  for  the  lack  of 
adeguate  system  protection. 

Three  different  types  of  information  were  identified 
as  being  necessary  to  the  implementation  of  a  recovery 
capability.   They  were: 

(1)  a  copy  of  each  user  task's  latest  memory  image, 

(2)  copies   of   all   current   values   for   system   control 
variables  and  tables, 

(3)  the  identity   of   the   task   runnina   when   the   crash 
occurred. 

The  use  of  swapping   made   the   first   type   of   information 
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readily  available  on  the  mini-disk  with  no  additional  action 
required.  To  this  point  in  the  design  it  had  not  been  found 
necessary  to  save  the  values  of  system  control  variables  and 
tables  anywhere  other  than  in  memorv.  This  oeficiencv  was 
rectified  by  introducing  the  concept  of  a  system  state  block 
(SSB)  . 

The  SSB  consists  of  a  compacts  contiguous  data  block 
in  the  system  area  of  memory  containing  all  control  data 
defining  the  state  of  the  system  at  each  instant.  The  SSB 
includes  information  such  as  the  status  of  each  user  task, 
virtual  floppy  disk  assignments;  the  location  of  eac^  swan 
file  on  the  mini-disk,  the  identity  of  the  task  currently 
allocated  the  CPU,  and  the  protection  attributes  snd 
locations  of  all  virtual  disk  files.  In  order  to  have  this 
information  available  should  recovery  be  reauired,  the  SSB 
is  copied  to  the  recovery  file  whenever  the  state  of  the 
svst em  chanaes . 

Taken  together,  the  four  swao  files  and  the  recovery 
file  contain  sufficient  information  to  restore  normal 
execution  after  a  system  crash.  The  third  item  required  for 
recovery,  the  identity  of  the  task  causino  the  crash,  is 
needed  to  delete  the  faulty  task  from  the  svstem.  The  swao 
file  for  this  task  contains  a  duplicate  of  the  memorv  image 
which  has  just  caused  the  svstem  failure.  If  this  same  task 
were  reloaded,  another  system  crash  would  likely  occur. 

One  final  point  must  be  mentioned  to  complete  the 
discussion  of  system  protection,  and  that  is  access 
protection.   Most  general  purpose  timesharing  svstems  employ 
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some  type  of  code  to  identify  individual  or  group  users  of 
the  system.  This  code  may  be  used  in  the  collection  of 
utilization  or  accounting  statistics*  or  simply  to  identify 
authorized  users  of  the  system.  It  was  decided  that  the 
access  protection  provided  by  such  a  code  is  not  a  necessary 
reguirement  for  MTS.  The  NFS  m i c rocomout e r  laboratory  Kas 
generally  followed  an  ooen  door  policy  which  permits  anyone 
with  an  interest  in  microcomputers  to  use  the  available 
facilities.  Conforming  to  the  spirit  of  this  open  lab 
policy*  access  protection  is  not  implemented  in  NTS. 

2 .   Virtual  Floppy  Disks 

The  protection  issue  surfaced  for  the  third  time  in 
the  implementation  of  virtual  f loory  disks.  In  this 
context/  protection  implies  privacy  and  security  for  virtual 
f 1 oopv  disk  files. 

From  the  viewpoint  of  privacy  ana  security  of  data» 
floppy  disks  provide  an  auxiliary  storaae  meaium  surpassed 
by  few  others.  The  physical  disk  is  small  in  size  and 
convenient  to  carry  or  store*  vet  provides  a  storage 
capacity  of  256  kilobytes*  eauivalent  to  1.6  card  sleeves. 
When  an  individual  finishes  an  operating  session  on  a  svstem 
eguipped  with  floppy  disk  drives*  he  need  only  physically 
remove  the  disk  from  the  drive  to  provide  whatever  physical 
protection  the  contents  merit. 

The  virtual  floppy  disks  provided  by  MTS  Ho  not 
afford  the  same  deoree  of  privacy  or  security  as  a  physical 
disk.   With   the   Sycor   440   hardware   confiquration   which 
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existed  when  this  was  written*  it  was  not  possible  to  codv  a 
virtual  floppv  disk  image  onto  a  physical  disk  for 
saf ekeepi  ng. 

In  order  to  provide  a  limited  degree  of  protection 
for  virtual  floopy  disks  it  was  decided  to  provide  three 
different  protection  attributes  for  virtual  floppy  disk- 
files: 

(1)  no  Protection  -  unlimited  access  for  read  or  write 

(2)  restricted  -  unlimited  access   for   read   only;   write 
access  only  if  the  file's  protection  key  is  known 

(3)  protected  -  read  and  write  access  only  if   the   file's 
protection  key  is  known. 

The  first  option,  no  protection,  applies  to  scratch 
disks  provided  for  temporary  storaae  or  work  snace.  Such 
files  should  be  available  to  any  user  as  reauired.  The 
restricted  attribute  allows  the  owner  of  a  oiven  virtual 
disk  file  to  make  the  contents  of  the  file  available  to 
others  on  a  read  only  basis.  This  level  of  protection  would 
apply  to  the  system  disk  containina  the  CP/W  operatino 
system.  The  protected  attribute  provides  complete 
protection  for  a  virtual  disk  file.  No  one  other  than  the 
file's  owner  or  someone  designated  by  the  owner  can  access 
the  file  either  to  read  or  write. 

Since  ^  T  S  does  not  reauire  user  identification 
codes*  the  protection  kev  feature  was  adooted  to  identifv 
the  owner  of  a  virtual  disk  file.  A  orotection  key  mav  be 
any  combination  of  zero  to  four  ASCII  characters  associated 
with  a  virtual  disk  file  when  the   restricted   or   orotected 
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attribute  is  set.  The  same  protection  kev  must  be  /  supplied 
by  a  user  attempting  to  write  to  a  restricted  file  or  read 
and  write  to  a  protected  file. 

C.   EXTERNAL  VIEW 

when  the  Sycor  44  0  Clustered  Terminal  Process inq  System 
was  delivered  to  the  MPS  microcomputer  laboratory,  the 
shipment  included  an  extensive  package  of  software  in 
addition  to  the  hardware  listed  in  chapter  ITI.  Tne 
existence  of  this  software  had  a  siqnificant  imoact  on  the 
design  of  MTS.  The  nature  and  extpnt  of  this  impact  is 
discussed  in  the  followina   paraqraohs. 


1.   Sycor  440/MTS  Interface 

The  Sycor  440  system  demonstrates  one  way  in  which 
microcomputer  technology  has  been  aoplied  to  commercial  data 
processing.  The  440  system  is  marketed  for  applications  in 
the  field  of  data  entry,  in  particular  data  entry  at 
locations  remote  from  a  central  processina  facility.  This 
intended  application  is  readily  apparent  in  the  software 
provided  by  Sycor  -  formatted  and  unformatted  keyboard 
input,  remote  job  entry,  report  generation,  communications, 
and  on-site  file  enquiry  ar»  prominently  featured.  The  440 
operating  system  and  file  management  facilities  also  reflect 
the  emphasis  on  data  entry.  ^ost  of  the  orogrammino  aids 
which  are  important  in  a  system  development  environment  are 
not  provided  by  the  Sycor  UH0  software  package.  There  is  no 
text   editor,  8080  assembler,  debugoing  program,  or  8080  hex 
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format  loader.  The  ooerating  system  is  larae»  allowing  only 
limited  memory  space  for  user  developed  programs.  Further, 
the  mini-disk  file  system  is  oriented  around  static 
allocation  of  fixed  size  files. 

The  Sycor  UHQ  operatinq  system  and  associated 
utility  programs  are  well  suited  to  the  data  entry 
application  for  which  they  were  designed.  At  the  same  timer 
they  do  not  provide  a  suitable  environment  for  microcomputer 
systems  develooment.  This  fact  provided  thp  initial 
motivation  for  the  develooment  of  MTS. 

Once  the  decision  had  been  reached  to  desian  and 
implement  a  separate  system  to  suoport  systems  develooment 
on  the  Sycor  4  4  0  hardware  there  were  basicallv  two  options 
open  with  regard  to  the  Sycor  suoolied  software: 

(1)  remove  the  Sycor  oDerating  system  and  associated  o  i  s  k 
files  to  make  more  memory  and  disk  soace  available  for 
MTS 

(2)  design  MTS  so  that  both  systems  might  be  available 
concur  rent  1 y . 

Option  2  had  the  desirable  effect  of  makinn  available  a 
resident  COBOL  compiler  and  a  PLMR  c ross-comoi 1 e r ,  both  of 
which  are  suooorted  by  the  Sycor  operatina  system.  Ootion  1 
allowed  the  greater  flexibility  in  the  design  of  MTS,  but 
reduced  somewhat  the  overall  capabilities  of  the  Sycor 
4  4  0  /  M  T  S  comoinatioo.  The  deciding  factor  in  select ino  thp 
second  option  for  implementation  was  a  desire  to  furnish  the 
system  affordina  the  maximum  potential  for  future 
development  while  still  meeting  project  goals. 
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2 .   File  System 

The  decision  to  make  the  Sycor  nperatinq  system  and 
MTS  concurrently  available  made  it  possible  to  imolement  MTS 
without  desianina  a  file  system.  The  file  management- 
facilities  provided  by  the  Sycor  operatina  system  proved 
adequate  to  handle  swapping,  recovery,  and  virtualized 
floppy  disks.  Const raininq  each  file  to  a  orede t e rw i ned 
fixed  size  was  not  difficult;  in  fact,  this  feature  of  the 
Svcor  file  system  simplified  considerably  the  virtual  disk 
mapoing  function  on  which  the  entire  virtual  f loopy  disk 
design  was  based . 

Four  different  tyoes  of  files  were  included  in  fhe 
final  MTS  design.   They  are: 

(1)  swap  files  -  four  files,  one  of  which  is  associated 
with  each  of  the  four  terminals,  containing  a  user 
program  memory  image 

(2)  recovery  file  -  a  s i nol e-sec tor  file  containing  a 
current  copy  of  the  system  state  block 

(3)  configuration  file  -  a  single-sector  file  containino 
the  user  defined  name  and  protection  attribute  for 
each  virtual  floppy  disk 

(4)  virtual  f 1 oopy  disk  files  -  a  maximum  of  32  different 
files,  each  containing  the  image  of  a  floppv  disk  as 
described  in  section  TV. A. 5. 

Three  of  these  four  file  tyoes  have  been  encountered  before, 
but  the  configuration  file  tyoe  reguires  some  additional 
explanation.  MTS  identifies  virtual  disks  by  a  logical  disk 
number  in  the  range  0  to  31.   Since  each  virtual  floppy  disk 
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actually  resides  in  a  mini-disk  file  created  under  the  Syccr 
operating  system*  there  must  be  some  mechanism  for  maopina  a 
logical  disk  number  into  a  file  name  contained  in  the  mini- 
disk directory.  There  is  an  additional  requirement  that  the 
protection  attributes  assigned  to  various  virtual  disk  files 
be  saved  between  MTS  operatina  sessions.  Poth  of  these 
functions  are    performed  by  the  configuration  file. 

The  confiauration  file  is  made  up  of  32  entries  of 
thirteen  bytes  each  contained  on  a  sinalp  mini-disk  sector. 
Each  entry  is  comooseri  of  a  zero  to  eight  byte  filename/  a 
zero  to  four  bvte  protection  key/  and  a  sinale  h  v  t  p 
protection  attribute.  The  loaical  disk  number  for  each 
entry  is  simply  the  position  of  that  entry  within  the  file. 

In  order  to  reduce  the  number  of  mini-disk  accesses 
reguired  to  service  virtual  f looov  dis<  I/O  requests/  it  was 
decided  to  read  the  configuration  file  into  memorv  on] v 
once/  during  NTS  initialization/  and  abstract  the  contents 
into  an  internal  data  structure  resident  in  memory.  This 
concept  was  expanded  later  to  include  the  mini-disk  file 
directory  as  well.  That  too  is  read  into  memory  durina 
initialization  and  searched  for  all  four  ^  T  S  file  types. 

D.   USER  PROGRAM  VIEW 

The  MTS  user  program  interface   consists   of   a   set   of 

service  routines   which   may   be   called   by  a  user  oroaram 

through  a  sinale  entry  ooint  to  perform  terminal  1/0/  access 

virtual  f 1 oopy    disks/    or   modify   the   user's   virtual 
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environment.  The  design  was  heavily  influenced  bv  the  CP/M 
operating  system  which  uses  a  similar  scheme  for  I/O  [23. 
The  use  of  exolicit  calls  to  MTS  for  I/O  was  an  undesirable 
limitation  necessitated  by  the  architecture  of  the  8080  CPU. 
Since  the  8080  is  a  sinale-state  machine  without  privileaed 
instructions/  the  hardware  orovides  no  facilities  for 
trapping  I/O  instructions. 

A  call  to  MTS  takes  the  form 

<value>  =  MTS (<f i d> , <oarm> ) . 
The  first  argument,  <fid>,  is  a  number  which  identifies  the 
function  to  MTS.  The  <oarm>  aroument  may  be  a  oaramefer 
valuer  if  only  a  single  oarameter  is  required,  or  the 
address  of  a  parameter  list  if  more  than  one  is  neeaed.  In 
each  case,  MTS  returns  <value>  upon  completion  of  the 
requested  operation.  This  returned  value  mav  be  an  A  SO  IT 
character  code,  an  error  code,  or  zero  if  the  value  has  no 
signi  ficance. 

The  services  available  to  a  user  may  he  logically 
divided  into  two  tvpes  of  calls  on  MTS:  (1)  system  calls, 
and  (2)  service  calls.  System  calls  Handle  creating, 
modifying,  and  deleting  attributes  of  a  user's  virtual 
environment.  As  a  minimum,  each  user  is  provided  with  a 
virtual  system  consisting  of  an  8080  CPU,  1 6K  bytes  of  RAM, 
a  terminal,  and  a  single  floopy  disk  drive  with  a  read-onlv 
copy  of  the  CP/M  operatinq  system  loaded.  T h i s 
configuration  is  the  system  default  environment  assumed  when 
the  user  loas  in.  Beyond  that  the  user  may  request: 
(1)  additional  memory  uo  to  a  maximum  of  48K  bytes 
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(2)  additional  floppy  disk  drives  uo  to  a  maximum  of  8 

(3)  attachment  of  any  virtual  floppy  disk  whose  protection 
key  is  known 

(4)  reboot  of  the  user's  system  from  drive  A  . 

Each  system  call  performs  the  same  function  for  a  user 
program  as  the  corresponding  terminal  system  command 
performs  for  the  user  at  a  terminal. 

Service  calls  provide  a  user  n  r  o  g  r  a  m  with  access  to  the 
terminal/  virtual  printer,  and  virtual  f  1  o  p  p  v  disks.  The 
details  of  the  terminal  interface  are  discussed  more  fully 
in  section  IV. F.  In  the  context  of  service  calls,  it  is 
important  to  note  that  attemptinq  to  read  from  a  terminal 
when  no  input  is  waitina  will  cause  the  request ina  task  to 
be  swapoed  out  and  blocked  until  inout  is  available. 

Before  a  user  proaram  can  access  a  carticular  virtual 
disk,  the  user  must  attach  that  disk  to  one  of  th<»  eioht 
virtual  disk  drives,  either  bv  making  a  system  call  to  M T S , 
or  entering  the  prooer  system  command  at  the  terminal.  (J nee 
a  virtual  disk  has  been  attached,  any  sector  within  that 
disk  is  accessed  by  sceci  fyina  a  comolete  sector  address  and 
a  DMA  buffer  address.  WTS  orovides  a  service  call  to  enter 
each  of  the  three  components  of  a  comolete  sector  address  or 
the  DMA  buffer  base  address  as  well  as  additional  calls  to 
read  or  write  the  specified  sector. 

In  the  section  which  discusses  the  VMM  concept  it  was 
mentioned  that  transparency  to  the  user  is  an  imoortant 
characteristic  of  a  WM.  The  attempt  was  made  in  the  design 
of   MTS   to   incorporate   this   same   feature.    nue   to  the 
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hardware  constraints  imposed  by  the  8080  CPU/  this  attempt 
was  not  entirely  successful.  There  are  several  olaces  in 
the  user  orogram/MTS  interface  where  the  operation  of  MTS 
could  not  be  hidden.  The  necessity  for  exolicit  calls  to 
MTS  for  I/O  services  has  already  been  mentioned.  The  manner 
in  which  interruots  are  handled  by  the  8080  also  impacts  on 
a  user  program.  Since  the  only  addressino  mode  provider!  by 
the  8080  is  direct  addressing,  the  fact  that  MTS  and  a 
user's  oroqram  occuoy  the  same  physical  memory  is  acparprt 
to  a  user  program  by  the  limits  on  the  user's  address  space. 

E.   TERMINAL  USFR  VIEW 

The  primary  interface  between  the  terminal  uspt  and  MTS 
is  provided  by  a  command  languaqe  interoreter  called  the  M IS 
Command  Processor  ( M C P ) .  This  interface  provides  the  user 
with  the  facilities  necessary  to  establish  and  modify  the 
working  environment.  The  user  can  aain  access  to  MTS 
through  system  commands  at  any  timer  even  though  currently 
communicating  with  a  subsystem  such  as  CP/M  or  other 
programs.  Access  is  accomplished  by  entering  the 
appropriate  command  at  the  terminal*  terminated  by  the  ERROR 
RESET  key.  This  signals  the  MTS  monitor  that  the  input  data 
is  a  system  command  to  be  processed  by  MCP. 

1.   MTS/MCP  Interface  Oesiqn 

One  of  the  desian  consideratons  for  a  command 
processor  in  an  interactive  timeshared  environment  is 
whether  it  shall  be  resident  or  non-resident.    The   actions 
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required  to  establish  and  modify  the  user's  environment  are 
not  normally  time  sensitive  nor  continuously  exercised  by 
the  user.  For  these  reasons*  recent  timesharing  systems 
have  commonly  implemented  the  command  processor  as  a  non- 
resident task  C16J •  Establishing  MCP  as  a  non-res i den t , 
swappable  task  was  given  serious  consideration.  However 
one  of  the  major  Sycor  4  4  0  hardware  limitations  affecting 
the  implementation  of  MTS  was  the  relatively  low  data 
transfer  rate  between  memory  and  the  mini-disk  (I. A. 3).  To 
meet  the  goal  of  reasonable  system  response*  minimi  zino  the 
number  of  swappina  tasks  became  one  of  the  r-1TS  design 
constraints. 

The  decision  was  made  to  design  MCP  as  a  resident 
but  completely  independent  module  of  M T S •  This  concept 
makes  the  MCP/MTS  interface  essentially  the  same  as  that 
between  any  users  pronram  and  MTS.  MCP  affects  changes  in 
the  user's  virtual  environment  by  calls  to  MTS  in  the  same 
manner  as  would  a  user  program.  There  are  two  primary 
differences  between  the  MCP/MTS  interface  and  a  user 
program/MTS  interface: 

(1)  The  entry  port  used  by  MCP  is  an  internal  MTS  entry 
point.  MTS  also  provides  an  external  entry  point  for 
use  by  user  programs.  The  reauirement  for  two  entrv 
points  resulted  from  the  decision  to  make  the  MCP  a 
resident  process.  The  distinction  is  necessary  to 
bypass  the  mechanism  which  blocks  user  proarams 
requesting  terminal  input  when  the  input  buffer  is 
empt  y . 
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(2)  MCP  must  save  and  restore  the  MTS  system  stack  pointer 
to  ensure  returninq  to  the  prooer  location  in  the  MTS 
monitor.  User  oroqrams  do  not  directly  interface  with 
the  MTS  monitor;  and  thus  are  not  concerned  with 
savina  and  restorina  its  stack  pointer. 

The  independence  of  data  structures  ana  system  call 
interface  features  were  maintained  for  ease  of  implement  inn 
MCP  as  a  swappable  image  at  some  future  time.  Uparaaina  tne 
Svcor  440  rrini-disk  controller  SDeed  ana  an  increase  in  the 
number  of  system  commands  available  to  the  user  would 
justify  imolementinq  the  MCP  as  a  non-resident  swapnable 
task. 

2.   System  Commands 

Since  the  system  command  1  a  n  q  u  a  q  e  is  the  terminal 
users  main  ooint  o*  contact  with  MTS,  the  features  and 
syntax  were  given  careful  consideration.  The  desion  coals 
were  to  develop  a  command  1 anquaoe  which  is  easy  to  learn 
and  easy  to  use. 

There  are  two  basic  sets  of  system-  commands 
available  to  the  user.  One  set  of  commands  allow  the  user 
to  establish  and  modify  the  environment.  These  include 
linking  the  terminal  to  MTS  (LOGIN);  specifying  virtual  disk 
drives  and  virtual  floopv  disks  to  be  attached  to  the 
environment  (ATTACH);  chanqina  the  memory  image  swap  size 
allocation  (SIZE);  and  unlinkina  from  MTS  (QUIT). 

The  second  set  of  commands  Drovide  the  user  with  a 
means  of  specify inq  protection  attributes  for  virtual  flopcv 
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disk  files.  These  include  addinq  the  protection  attrioute 
to  a  specified  virtual  floppy  disk  (PROTECT);  addino  the 
restricted  attribute  to  a  orotected  virtual  flonpy  disk  to 
allow  read  access  bv  other  users  (RESTRICT);  and  to  remove 
all  previous  protection  attributes  from  a  virtual  flocpv 
disk  (UNPROTECT). 

The  function/  syntax,  parameters,  description  and 
associated  error  messaoes  for  each  command  are  described  in 
detail  in  section  D .  3  of  Appendix  A. 

F.   TERMINAL  INTERFACE  DESIGN 

The  four  terminals  attached  to  the  Sycor  4a0  svst-e-n 
provide  the  user  with  a  CRT  disolav  and  tynewriter-like 
keyboard  for  entering  oata.  A  brief  description  of  the 
terminal  hardware  is  contained  in  chapter  III.  The  factors 
affecting  the  terminal  interface  desian  included: 

(1)  Long  delays  between  key  depression  and  apoearance  of  a 
character  on  the  terminal  display  are  unacceptable  to 
the  user . 

( 2 )  The  characters  displayed  at  each  terminal  are  a  DMA 
image  of  characters  located  in  the  Svcor  440  main 
memo  ry . 

(3)  The  terminals  have  very  primitive  hardware  display 
logic.  Thus  software  is  required  to  accomplish  such 
tasks  as  converting  a  keyboard  matrix  code  to  ASCII 
code  for  each  key  depression?  blinkina  the  current 
position   indicator   (cursor),    and    scrollina    the 
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display. 

1.   Design  Decisions 

MTS  was  desioned  to  provide  a  virtual  terminal 
interface  for  programs  reauestinq  terminal  I/O.  This 
interface  simulates  the  ooerat ion  of  a  serial  half-duplex 
console  device.  For  input  of  data/  the  user  program 
requests  characters  one  at  a  time  throuqh  service  calls  to 
MTS.  If  input  is  available/  the  next  character  is  returned 
to  the  requesting  program.  Outcut  is  handled  in  a  similar 
fashion  with  the  user  proaram  providinq  an  ASCII  character 
code  as  an  aroument  in  the  aporcoriate  service  call.  A 
service  call  is  made  for  each  character  to  be  aisplayea. 
For  each  request  received  by  M  T  S  /  the  character  is  displaved 
by  placinq  it  at  the  current  cursor  oosition  in  the 
appropriate  terminal's  DMA  disolay  buffer.  The  only 
characters  not  olaced  in  the  display  buffer  on  output  are: 
carriage  return  (CR)/  which  returns  the  cursor  to  the 
leftmost  position  of  the  current  line?  and  line  feed  (LF) , 
which  moves  the  cursor  oosition  down  one  line.  The  outnuf 
of  a  data  seauence  is  normally  terminated  by  a  CR/LF 
character  combination.  MTS  also  provides  a  terminal  status 
service  call  which  allows  a  user  program  to  test  whether 
input  data  is  available  for  processinq  CD. 3).  This  function 
could  be  used  to  test  for  a  break  kev  indication  durina 
output  by  the  user  oroqram. 

Due  to  the  unavoidable  delays  in  user  program 
response  caused  by  swapping  and  aqqravated  by  the  relatively 
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low  data  transfer  rate  of  the  mini-disk,  the  MTS  terminal 
interface  was  designed  to  provide  character  echoino  and 
simple  line  editing.  This  ensured  reasonable  response  times 
to  key  activation  bv  the  user,  even  though  his  program  was 
not  currently  in  memory.  Each  character  key  activated  at  a 
keyboard  results  in  the  appropriate  character  being 
displayed  on  the  CRT  by  MTS.  The  line  editing  features  are 
discussed  in  section  3  below. 

There  are  four  576  by*"e  DWA  terminal  buffer  areas 
located  in  RA^.  Thus,  a  ?304  byte  area  of  the  Sycor  aaO's 
main  memory  has  been  allocated  by  the  system  hardware  design 
for  terminal  disolay  buffers.  To  take  maximum  advantaae  of 
this  memory  utilization,  the  decision  was  made  to  use  this 
area  as  the  input  holding  buffer  as  well  as  the  display 
buffer.  This  eliminated  the  need  for  additional  input 
buffers  and  the  extra  processinq  time  required  to  move  a 
completed  input  line  to  a  separate  buffer. 

2.   Display  Description 

The  first  64  disolay  character  positions  of  each 
terminal  are  physically  separated  from  the  regain i no  512 
character  positions  by  a  blank  line.  This  led  to  the 
decision  to  reserve  the  first  line  for  displav  of  status  and 
error  messages.  All  inout  and  output  of  data  was  to  be 
accomplished  in  the  remainino  51?  character  positions. 
Thus,  each  576  byte  terminal  buffer  is  logically  divided 
into  two  separate  buffers,  as  follows: 
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The  numbers  are   decimal   and   specify   character   positions 
within  the  status  line  and  display  buffer. 

The  terminal  status  line  is  used  by  ^  T  S  to  displav 
three  types  of  status  information:       \ 

(1)  The  current  virtual  drive  and  floooy  disk  assianments 
for  that  terminal. 

(2)  The  size  of  the  user's  swap  i  m  a  a  e  ,  i.e.  the  amount  of 
memory  space  currently  available. 

(3)  Error  messaqe  alerts  oroduced  by  MTS  system  commands, 
or  resulting  from  user  program  calls  on  the  OISPLAY 
MSG  service  routine  (see  section  F.2  of  Aopendix  A ) • 

The  status  line  display  format  and  contents  are    discussed  in 
detail  in  section  E  of  Apoendix  A. 

As  indicated  by  the  above  format  description,  the 
display  buffer  can  hold  a  maximum  of  512  characters  (8  lines 
on  the  CRT).   As  previously  mentioned,  this  Duffer  not   onlv 
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provides  the  display  of  characters  but  also  acts  as  an  input' 
buffer/  hold i no  the  input  data  until  the  user's  program 
requests  it.  Since  MTS  provides  simple  line  editinq  of 
input  data*  this  data  can  not  be  considerea  available  to  the 
user's  program  until  an  input  line  termination  character  has 
been  received  by  MTS.  To  establish  an  input  Duffer  for  a 
program^  the  user  enters  the  data  and  terminates  the  line  bv 
hitting  the  NEWLINE  or  ENTER  kevs  on  the  keyboard.  This 
establishes  that  line  as  an  inout  buffer  available  for 
processing  by  the  user's  program.  Note  that  the  kjv 
combinations  'I/O  CTL  M"  or  'SHIFT  CR'  (on  the  number  pad) 
will  also  result  in  the  termination  of  an  input  line. 
Either  of  these  keys,  as  well  as  NEWLINE  and  ENTER/  may  be 
used  for*  line  termination. 

Once  an  input  buffer  has  been  established  the  user 
may  continue  to  input  data  on  the  next  line.  The  user  m  a  v 
use  any  of  the  line  editing  or  other  cursor  control  features 
on  this  new  line  of  inout  data.  However/  this  n<ew  line  mav 
not  ba  teroinated  until  the  user's  program  has  processed  the 
previous  inout  buffer  (see  terminal  alerts  below). 

Each  character  output  from  the  user's  program  is 
disolayed  at  the  current  cursor  oosition.  Each  output 
results  in  all  input  buffer  pointers  beina  reset  to  the 
character  oosition  at  the  end  of  the  output  data.  Thus/ 
subsequent  I/O  will  start  at  tnis  ooint.  This  implies  that 
if  the  user  had  been  in  the  middle  of  enterina  data  when  the 
output  occurred/  it  must  be  reentered. 

The  MTS  terminal  interface  provides   the   user   with 
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either  a  visual  or  audio  response  to  each  key  depression. 
Normal  visual  resoonse  is  provided  by  disolay  of  the  entered 
character  (echoino)  and/or  movement  of  the  display  cursor. 
The  display  cursor  is  a  blinking  underscore  character  which 
marks  the  current  position  on  the  screen.  Data  is  always 
entered  and  disolayed  at  the  current  cursor  position. 

The  audio  responses  consist  of  either  a  beep  or 
click  at  the  terminal.  A  terminal  been  alert  will  oe 
generated  for  any  of  the  following  conditions: 

(1)  An  input  buffer  is  waitinq  to  be  processed  by  the 
user's  oroaram  and  the  terminal  user  attempts  to 
terminate  a  new  input  line. 

( 2 )  An  attempt  is  made  to  move  the  cursor  back  past  the 
start  of  the  current  line.  For  example*  attempting  to 
delete  the  previous  line  or  character  after  the  line 
has  been  entered  by  a  termination  key  will  result  in  a 
beep . 

The  terminal  click  alert  is  associated  with  the 
display  scrollina  feature.  Since  the  display  buffer  also 
acts  as  an  inout  buffer*  scrollina  the  disolay  when  the  512 
byte  disolay  buffer  is  full  could  destroy  input  data  which 
has  not  yet  been  processed.  For  example*  the  user  could  be 
entering  a  512  character  strinq.  Unon  termination  of  that 
input  line*  MTS  will  prevent  scrollina  until  the  user's 
proaram  has  processed  the  first  64  characters.  This  ensures 
that  the  inout  data  is  not  destroyed  bv  the  scrolling 
operation.   This   scrolling  lockout  is  indicated  to  the  user 
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bv  a  terminal  click  alert. 

3.   Terminal  Key  Functions 

The  terminal  keys  fall  into   five   basic   functional 
groups : 

(1)  Character  string  keys  -  these  are  the  alphanumeric  and 
SDecial  character  kevs  normally  available  to  the  user 
for  input  of  data.  Alphabetic  characters  are  entered 
and  displayed  in  either  upper  or  lower  case,  dependina 
on  the  key  Tiode  (see  below).  The  tab  Key  causes  the 
entry  and  display  of  a  special  tab  character*  no 
blanks  are  oadded  in  for  tabs. 

( <? )  Entry  mode  kevs  -  these  keys  define  the  interpretation 
of  keys  for  special  functions  or  alphabetic  upper 
case.  These  include  the  FUNCTION  SELECT,  I/O  CONTROL, 
and  SHIFT  keys.  In  addition,  the  key  combination 
FUNCTION  SELECT  and  C  sets  or  clears  the  alphabetic 
key  entry  mode  to  upper  or  lower  case.  This  functions 
as  a  shift  key  loc<  because  a  phvsical  lock  is  not 
provided  with  the  terminal  keyboara. 

(3)  Line  termination  keys  -  these  keys  define  the  termi- 
nation of  an  input  line  of  data.  Input  aata  to  be 
processed  by  the  user's  program  must  be  terminated 
with  one  of  the  followina  keys  or  key  combinations: 
NEWLINE;  ENTER;  I/O  CTL  M;  or  SHIFT  CR.  Their 
function  was  discussed  in  the  preceeding  section. 
Another  termination  key  is  ERROR  RESET,  which 
specifies   that   the  input  line  it  terminates  is  to  b^ 
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processed  by  WTS  as  a  system  command. 

(4)  Line  editing  and  cursor  control  keys  -  these  keys 
provide  the  simple  line  editino  features  such  as  line 
delete  (NEXT  FMAT);  character  delete  (BACKSPACE); 
clear  screen  (FS  $  or  I/O  CTL  $);  and  move  cursor  left 
or  right  (<--  ;  -->). 

(5)  Number  pad  keys  -  consists  of  10  numeric  dioits  ana  8 
ASCII  control  characters  located  on  the  riaht  side  of 
the  keyboard.  The  digits  function  in  the  same  manner 
as  the  other  numeric  digits  on  the  keyboard.  Thp 
ASCII  control  characters  are  displayed  when  the  SHTFT 
key  is  depressed  in  conjunction  with  the  appropriate 
key.  The  only  control  character  which  affects  the 
disdav  is  SHTFT  CH  (see  line  termination  keys). 

All  terminal  keys  and  their  functions  are    described  in   more 
detail  in  section  D.2  of  Apoendix  A. 

G.   CHOICE  OF  A  PROGRAMMING  LANGUAGE 

Following  the  design  phase*  it  was  necessary  to  choose 
an  appropriate  orogrammina  language  to  be  used  in  the 
implementation  phase  of  development.  An  obvious  reouirement 
was  that  the  1 anguace  selected  must  suDport  system 
programming  for  the  8080  microprocessor.  Other  factors 
involved  in  choosing  a  language  for  the  MTS  development 
included  the  following: 

(1)  Efficiency  of  the  code  qenerated  by  the  assembler*  or 
compiler.   An  important  consideration  in  any  operatina 
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system  development  is  minimizing  the  amount  of   memory 
and  processinq  time  utilized  by  system  routines. 

(2)  Ease  of  access  to  machine  resources  (e.g.  registers, 
memory/  I/O  ports,  stack,  etc.)  throuqh  the  constructs 
provided  by  the  lanauage.  This  must  be  considered 
whenever  developing  software  which  will  be  interfacino 
with  the  bare  machine. 

(3)  The  availability  of  the  assembler  or  compiler  for 
development  work.  The  turn-around  time  for  assembly 
or  compile  tasks  and  the  debug  aids  provided  by  a 
language  ar^     important-  factors. 

(4)  The  inclusion  in  the  languaae  of  convenient  confol 
structures  and  self- documentation  features  similar  to 
those  found  in  most  hiqh-level  structured  lanauages. 
It  has  been  shown  that  these  features  assist  in  r  a  o  i  d 
system  development  and  checkout,  straightforward 
maintenance  and  modification,  and  a  highly  reliable 
system.  It  was  envisioned  that  M T S  would  be  enhanced 
and  modified  extensively  as  the  requirement  for 
additional  m i c rocomout er  development  facilities 
increased.  Thus,  ease  of  future  modification  and 
maintenance  was  a  prime  consideration. 

(5)  The  ability  of  the  assembler  or  compiler  to  generate 
error  free  code  was  important  for  ease  of  roding, 
testing,  and  debuggino  the  system  modules  during 
project  development. 
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There  were  three  lanauages  available  at  NPS  which 
supDorted  programming  for  the  8080  microprocessor.  The 
following  is  a  brief  description  of  these  lanauaqps  and 
their  advantaaes  and  disadvantages: 

(1)  8080  Assembly  Lanauage  f81  -  the  assembly  1 anquage 
developed  for  use  with  the  8080  microprocessor.  It 
satisfied  (1)  and  ( 2 )  above  by  o  r  o  v  i  d  i  n  a  efficient  and 
direct  access  to  the  machine  resources.  Item  (3)  was 
satisfied  because  a  resident  assembler  and  dynamic 
debugging  tool  were  available  on  an  TIMTE.LLEC  ti/MOD  80 
microcomputer  system  for  use  during  the  project 
development.  The  major  limitation  in  usina  an 
assembly  1 anguaae  is  its  failure  to  satisfy  item  fa). 

(2)  ML80  [12]  -  a  structured  system  Programming  language 
for  the  8080  microDrocessor  develoDed  as  a  tresis 
project  at  NPS.  It  is  composed  of  two  independent 
languages:  M80  -  a  macro  oriented  language?  and  l_ 8 0  - 
a  machine  oriented  language.  It  incorporates  such 
features  as:  control  structures*  similar  to  those 
found  in  most  high-level  structured  languages?  allows 
full  use  and  control  of  the  resources  of  the  8080 
microprocessor  through  the  use  of  algebraic  notation 
for  mach i ne* 1 e ve 1  register  and  data  operations: 
provides  compile-time  features*  such  as  expression 
evaluation*  conditional  compilation*  and  macros?  and 
provides  load-time  facilities*  such  as  the  linKino  o  * 
precompiled  procedures  into  the  object  program 
(generates  relocatable  code).   It  was   also   available 
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as  a  resident  compiler  on  the  INTELLEC  K/MOD  80.  Thus 
to  some  degree*  M|_80  satisfied  all  the  considerations 
mentioned  above  except  (5).  That  is*  it  had  never 
been  used  for  a  larqe  system  development  and  thus  its 
performance  in  that  environment  was  untested. 
(3)  P L / M  [91  -  a  hiqh-level  prooramming  lanauaqe  desiqneH 
to  provide  system  proaramminq  for  the  8  0  8  0 
microorocessor.  It  was  desiqned  to  facilitate  the  use 
of  modern  techniques  in  structured  programmino.  Thus* 
it  came  the  closest  in  satisfyina  consideration  f 4 ) 
above.  However*  its  major  disadvantaoe  was  in 
qeneratinq  less  efficient  code  and  allow i no  less 
direct  access  to  the  machine  resources  than  the 
oreceedino  two  lanquaaes. 

After  considering  the  advantaaes  ana  d i sadvant aaes  of 
the  languaqes  available*  the  decision  was  made  to  utilize 
ML80  as  the  primary  development  lanauage  for  ^TS.  A  surtask 
of  the  thesis  oroject  was  to  test  W  L  8  0  as  a  orogrammino 
language  in  a  larqe  system  development  environment.  Results 
of  using  ML80*  including  recommended  enhancements  to  tne 
language  and  it's  facilities*  are  included  in  the  remain  inn 
chapters . 
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V.   MTS  IMPLEMENTATION 


Top  down  svstem  design  and  modular  programming  are 
current  software  enaineering  concepts  which  stronnly 
influenced  the  design  and  implementation  of  ^TS.  As  each 
SDecific  functional  reguirement  of  a  times^ared 
microcomputer  system  was  identified*  a  new  module  was  added 
to  the  MTS  desian  to  satisfy  the  recuirement.  An  effort  was 
made  to  make  each  logical  module  an  indeDenaent  entity 
communicating  with  other  system  modules  through  a  s imple* 
well-defined  interface.  This  same  concept  was  also  aoolied 
to  the  implementation  phase  of  development.  Each  loaical 
module  was  imolementec  as  a  separate  code  module  with  the 
fewest  possible  number  of  intermodule  linkages.  Five 
modules  were  needed  to  meet  the  Drocessing  and  resource 
sharing  reguirements  imoosed  by  timesharing.  In  addition  to 
these  code  modules*  a  sixth  declaration  module  was  included 
to  define  the  underlying  data  structure. 

Use  of  MLPO  as  the  implementation  lanauage  for  MTS 
affected  the  development  primarily  in  the  area  of  module  and 
data  structure  linkages.  The  problems  encountered  can  be 
attributed  mainly  to  the  limited  memory  si?e  (lt>K)  o*  the 
INTELLEC  8/MOD  flO  which  hosted  the  MLBO  compiler.  Due  to  the 
relatively  small  amount  of  work  area  available*  many  of  trie 
compiler's  tables  and  stacks  were  too  small  to  satisfy  the 
demands  of  MTS,   This  size  limitation  forced  a  corresponding 
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limitation  on  the  size  of  individual  M  T  S  modules  and 
submodules.  The  effect  of  forcina  a  decrease  in  the  natural 
size  of  the  MT S  proqram  modules  was  to  increase  the  1 inkaqe 
requirements  between  these  modules.  The  ML80  comoi ler 
provides  some  link  editina  facilities*  but  does  not 
conveniently  suoport  the  numerous  linking  requirements 
encountered  in  the  development  of  MTS. 

A.   SYSTEM  STATE  BLOCK 

The  management  functions  performed  by  M1S  may  be  divided 
into  task  management  and  resource  management.  Task 
management  is  concerned  with  the  control  and  reco rd-keep i no 
functions  necessary  to  supnort  ud  to  four  concurrent  tasks. 
Resource  management  provides  the  same  functions  for  fhe 
hardware  resources  of  the  Sycor  440.  Both  tyres  of 
management  involve  recordino  status  information  for  later 
use  in  processing  control.  Considered  jointly*  this  status 
information  defines  the  state  of  the  MTS  svstem  and  forms 
the  basis  of  the  MTS  data  structure. 

In  the  implementation  of  MTS  it  was  found  necessary  to 
combine  all  status  information  into  a  logical  and  physical 
block  called  the  system  state  block  (SSB).  This  approach 
was  originally  adopted  to  reduce  the  overhead  of  the 
recovery  feature.  The  status  information  contained  in  t-he 
SSB  must  be  copied  to  a  recovery  file  after  each  swap.  By 
consolidating  this  data  into  a  comoact*  contiguous  block, 
only  a  single  mini-disk  access  was  required. 
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Subsequent 1 y f  it  was  found  desirable  to  combine  all 
variables  referenced  by  two  or  more  NTS  modules  into  a 
sinqle  declaration  module  with  alobal  scone.  This  improved 
the  readability  of  the  source  o  r  o  g  r  a  m  ,  simplified  proqram 
debugoing*  and  facilitated  maintenance  of  the  system.  The 
SSB  is  logically  composed  of  three  distinct  elements: 

(1)  task  control  table  -  contains  information  on  tne  state 
of  each  task  and  data  reauirea  to  support  swapninq. 
Each  variable  contains  four  entries  -  one  for  each  of 
the  four  terminal  tasks. 

(2)  disk  man  table  -  contains  information  on  the  status, 
protection  attributes/  and  mini-disk  location  o*  all 
virtual  floooy  disks.  Each  variable  contains  32 
entries  -  one  for  each  of  the  32  possible  virtual 
f 1 oopy  disks. 

(3)  system  control  variables  -  single  variables  referenced 
by  several  modules*  e.o.  the  swap  lock  and  the  number 
of  the  task  currently  executing. 

Each  task  control  table  and  disk  map  table  entry  was 
actually  implemented  as  a  named  byte  vector  indexed  by  t-he 
task  number. 

B.   MONITOR  MODULE 

The  monitor  module  incorporates  all  of  the  task 
management  functions  required  by  M T S  into  a  physical  1 y  and 
logically  distinct  module.  Included  in  this  module  ar* 
routines   which   handle   the  loading  of  a  task,  schedulina  a 
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task  for  execution*  swaoping  tasks  between  memory  and  the 
mini-disk,  and  deleting  a  task  after  an  irrecoverable 
hardware  error.  Due  to  the  module  size  limitation  imposed 
bv  the  16K  ML80  compiler*  it  was  necessary  to  divide  the 
monitor  into  utility  and  task  manaaement  submodules  for 
compilation.  A  third  submodule*  containing  the  initial 
proaram  load  routines*  was  included  in  the  physical  monitor 
module  for  reasons  of  convenience  rather  than  loqical 
continuity. 

1.  Utility  Submodule 

It  was  found  convenient  in  the  implementation  of  M T S 
to  develop  a  qrouo  of  utility  routines  r o  handle  recurring 
primitive  operations  reguired  to  access  entries  in  the 
system  state  block.  Since  ^  o  s  t  SSd  entries  are  indexed  bv 
either  a  task  number  or  a  virtual  disk  number,  a  significant 
savings  in  memory  space  was  realized  by  reolacina  in-line 
code  segments  with  calls  to  a  utility  for  indexing 
operations.  The  convenience  of  having  these  primitives 
available  was  offset  somewhat  by  the  necessity  to  compile 
the  utilities  submodule  independent  1 v  of  the  callinq 
rout  i  nes . 

2.  Task  Management  Submodule 

The  life  cycle  of  a  task  in  a  multiproorammed 
environment  i^av  be  represented  by  a  series  of  transitions 
between  process  states.  Tt  is  the  job  of  the  operatinn 
system  to  control  and  monitor  these  transitions  [10J.  In 
the  MTS  operating  system  this  function  is  performed   by   the 
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task  management  submodule. 

Each  user  task  in  the  MTS  environment  may  exist-  in 
one  of  the  following  states: 

(1)  logged  in  -  task  is  active  but  not  vet  loaded 

(2)  hold  -  task  requires   the   services   of   the   terminal 
command  processor  to  alter  its  virtual  environment 

(3)  blocked  -  task  is  waiting  for  the  completion  of  an  I/O 
operat  i  on 

(4)  ready   -   task   is   waiting   for*   the   CPU   to   become 
avai 1 ab 1 e 

(5)  running  -  task  has  been  allocated  both  memory  and   the 
CPU 

The  current  state  of  a  task  is  determined  Ov  the  bit  pattern 
set  in  the  status  byte  associated  with  that  task.  bach  Hit 
of  this  status  bvte  corresDonds  to  a  different  process 
state*  and  there  is  a  different  status  bvte  associated  with 
each  task.  Since  the  information  contained  in  the  task 
status  bytes  is  an  important  part  of  the  overall  svstem 
status*  they  are    located  in  the  system  state  block. 

The  processina  performed  by  the  MTS  monitor  is 
driven  by  the  values  of  the  task  status  bytes.  when  the 
monitor  is  entered  it  sets  a  task  counter  to  the  number  of 
the  task  currently  runnina*  increments  the  counter,  and  then 
examines  each  bit  of  the  status  byte  indexed  by  this 
counter.  If  it  finds  a  hit  set/  it  calls  the  appropriate 
routine  to  affect  the  state  transition  imolied  by  the  task's 
current  state.  In  the  event  no  bits  are  set,  the  task 
counter  is  again  incremented  and  the  process  repeated. 
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Note  that  the  task  status  byte  days  three  different 
roles  in  the  manaqement  of  user  tasks: 

(1)  It  drives  the  ooeration  of  the  monitor. 

(2)  It  provides  the  simplest  possible  interface  between 
the  monitor  and  the  terminal  command  processor.  The 
MCP  need  only  set  the  appropriate  bit  to  inform  the 
monitor  that  a  new  task  has  enterea  the  system. 

(3)  It  allows  the  terminal  interface  module  to  inform  the 
monitor  that  a  system  command  has  been  entered  without 
interruotinq  the  current  task.  This  feature  was 
implemented  to  reduce  the  swapDinq  overhead  of  svstem 
command  processina  while  «*  t  i  1  1  allowing  MCP  t-  o  be  a 
swaopab 1 e  task. 

Implicit  in  the  sequential  examination  of  bits  carried  out 
bv  the  monitor  is  a  hierarchy  of  orocess  states.  Since  both 
the  terminal  interface  module  and  the  M  C  P »  as  well  ^  s  ••he 
monitor  itself/  may  set  various  bits  in  the  status  cvte 
independently  of  each  other,  some  method  of  resolvina 
conflicts  was  necessary. 

3.   Initial  Proaram  Load  Submodule 

While  not  logically  a  part  of  the  task  management 
function,  the  IPL  submodule  has  an  important  influence  on 
the  operation  of  the  monitor  after  MTS  is  loaded.  The 
preceding  section  described  how  the  SSB,  particularly  the 
task  status  byte*  drives  the  operation  of  the  monitor.  The 
primary  task  of  the  I P  L  submodule  is  loading  values  into  the 
SSB  oefore  ^TS  is  executed.   Two  loadina  options   have   been 
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implemented:   initialization  and  recovery. 

The  recovery  option  is  the  simplest  and  most 
straightforward  of  the  two.  As  discussed  in  section  IV.R.1 
the  four  swap  files  and  the  recovery  file  together  contain 
all  the  information  MTS  needs  to  recover  after  a  system 
failure,  IPL  process  ina  is  limited  to  searchina  the  Sycor 
file  directory  for  the  recovery  file's  sector  address  ani 
then  reading  the  file  into  the  SSB. 

A  areat  deal  more  process ina  is  reauirea  to 
initialize  MTS.  Again,  the  Sycor  file  directory  must  be 
searched  -  this  time  for  all  four  swap  files,  the 
configuration  file,  and  the  recovery  file.  Assuming  that 
the  six  MTS  system  files  are  found,  the  IPL  submodule  then 
reads  the  con f i aura t i on  file  and  searches  the  Sycor  file 
directory  for  each  virtual  floppy  a  i  s  k  file.  For  every  file 
founa  in  the  directory,  system  or  vi  rfual  floopy  disk, 
beginning  and  ending  sector  numbers  must  be  recorded  in  the 
TCT  and  D ,M  T  respectively.  Initialization  of  the  0MT  also 
reguires  that  protection  kevs  and  attributes  must  De  copied 
from  the  configuration  file. 

The  IPL  submodule  provides  the  only  internal 
interface  between  MTS  and  the  Sycor  operating  system,  i.e. 
the  file  directory.  This  submodule  is  also  the  only 
routine,  other  than  the  timer  handler  in  the  interrupt 
module,  which  calls  the  monitor.  The  final  distinguishing 
feature  of  the  IPL  submodule  is  that  it  is  the  only  non- 
resident module  of  MTS.  Since  IPL  is  only  reauired  once, 
immediately   after  MJS  is  loaded,  the  code  was  written  to  oe 
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loaded  in  the  user  area  of  memory.  Once  normal  operation 
begins*  the  IPL  submodule  is  overlaved  by  the  first  user 
task  which  is  loaded. 

C.   INTERRUPT  MODULE 

The  Sycor  440  provides  a  comorehens i ve  set  of 
prioritized  interrupts.  Each  hardware  interrupt  causes  the 
execution  of  an  8080  RESTART  1  (RST  1)  instruction.  This 
instruction  behaves  like  a  call  to  location  0008H.  That  is, 
it  results  in  the  procram  counter  value  beina  Dushert  onto 
the  current  stack  and  control  beina  transferred  to  location 
0008H.  Due  to  this  hardware  characteristic,  user  proorams 
must  ensure  that  any  user  defined  stacks  are  at  least  four 
bytes  larger  than  the  maximum  size  reauired  by  the  user's 
own  code.  This  will  ensure  that  the  stacks  will  not 
overflow  if  their  program  is  executina  when  an  interrupt  is 
generated. 

Since  all  interrupts  cause  execution  of  the  same 
interrupt  instruction,  some  means  must  be  available  to 
determine  which  device  qenerated  the  interrupt.  The  Sycor 
440  solves  this  problem  by  defining  an  interrupt  level  for 
each  different  device.  There  are  17  interrupt  levels  with 
values  ranging  from  0  to  16.  The  priority  of  interrupts  is 
established  by  assiqning  a  hiaher  orioritv  t-  o  a  device  with 
a  hiqher  numeric  value.  When  an  interrupt  occurs  the  level 
used  to  identify  the  initiating  device  is  available  on  a 
SDecific  input  port.   Simultaneous  interrupts  will  be  placed 
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on  the  interrupt  input  port  in  a  priority  sequence.  That 
is*  the  levels  will  be  input  in  descendinq  sequence  by  level 
number.  When  the  level  on  the  input  nort  is  zero  all 
pendinq  interrupts  have  been  orocessed.  The  interrupt  input 
port  number  and  the  interrupt  level  assignments  which  apply 
to  the  current  NPS  Sycor  4  '1 0  hardware  configuration  are 
contained  in  Ref.  1. 

The   interrupt   module   processes   two   basic   interrupt 
cat eqor  i  es : 

(1)  timer  interruot  -  this  interrupt  is  qenerated  c  v  an 
internal  clock  once  ev^rv  5flmsr  when  it  has  been 
enabled.  This  crovides  MTS  with  tne  capability  of 
accomplishing  tasks  which  must  be  done  on  a  periodic 
basis.  It  also  provides  M  T  S  with  the  means  for 
regaining  control  of  the  system  from  a  user  prooram. 

(2)  device  interrupts  -  these  interrupts  are  qenerated  bv 
a  soecific  oeripheral  device  to  indicate  the 
completion  of  a  task  or  a  request  for  service.  Th^ 
processino  of  these  interrupts  is  device  dependent. 

1.   Data  Structures 

The  interrupt   module   consists   of  two   parts*   an 

interrupt  controller  and  a  set  of  interruot  handlers.   There 

is  an  interruot  handlina  routine  for   each  interruot   level 

orocessed  by  M  T  S .  The  data  structures  reouireP  dv  the 
interruot  module  include: 

(1)  interruot  stack  -  a  30  byte  data  vector  used   to   save 

the   current  system  environment  prior  to  any  interruot 
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processing   and   to   restore   the    environment    upon 
completion  of  interrupt  processina. 

(2)  blink  timer  -  a  sinqle  byte  used  to  store  the  current 
value  of  the  periodic  terminal  processing  counter. 
This  counter  is  decremented  once  every  50ms  and  is 
used  to  determine  when  to  blink  the  cursor  character 
at  each  terminal . 

(3)  task  timer  -  a  global  system  variable  used  to  control 
a  user  task's  timeslice. 

(4)  lock  -  a  global  svstem  variable  used  to  lndic^tp 
swapping  lockout. 

2.       Interrupt  Processing 

Durina  ^TS  initialization,  locations  0008-OOOAH  ar^ 
loaded  with  a  jump  instruction  to  the  interrupt  controller. 
Thus,  when  an  interrupt  occurs*  the  interrupt  controller  is 
called.  It  saves  the  current  environment,  identifies  the 
interrupt  level  and  calls  the  appropriate  handler  routine. 
Upon  return  from  the  interrupt  handler,  the  controller 
checks  the  interrupt  input  port  to  determine  if  any  more 
interrupts  are  pending.  If  so,  the  seouence  is  repeated; 
otherwise  the  environment  is  restored,  interrupts  enabled, 
and  control  returned  to  the  interrupted  process. 

The  interrupt  handlers  oroviae  the  following 
processing: 

(1)  timer  handler  -  manages  the  two  functions  of  ^  T  S  which 
occur  at  periodic  intervals.  These  are  blink  inn  the 
terminal  cursors  and  returnina  control  to   the   system 
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when  a  task's  timeslice  expires.  Tn  order  to  keep 
track  of  the  two  intervals  involved/  two  counters  are 
maintained.  These  counters  are  each  set  to  an  initial 
value  and  then  decremented  each  time  a  timer  interrupt 
occurs.  The  actual  value  contained  in  either  counter 
represents  the  time  remainino  in  the  interval  in 
multiples  of  SOms.  When  the  blink  timer  reaches  zrrn 
the  appropriate  routine  is  called  to  blink  the  cursor 
character  at  each  terminal.  When  the  task  timer  is 
zero  a  check  is  made  to  see  if  swapoing  is  lockpo  out. 
If  not/  the  current  environment  is  moved  to  the  s  w  a  o 
stack  and  control  is  transferred  to  the  V. TS  monitor. 

(?)  terminal  handler  -  processes  the  interruDt  generafed 
by  a  character  key  depression  at  one  of  the  four 
terminals.  Tt  retrieves  the  terminal  identity 
responsible  for  generatina  the  interrupt  and  the 
associated  keyboard  matrix  code  from  the  appropriate 
input  port.  The  terminal  input  control  routine  is 
then  called  to  complete  the  key  processina  (see 
Terminal  Interface  Module). 

(3)  other  device  handlers  -  the  remaining  device  handlers 
(e.g./  cassette  and  printer  handlers)  were  designed 
but  not  implemented.  The  present  implementation 
simply  clears  the  interrupt  status  and  returns. 
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D.   SERVICE  MODULE 

The  most  visible  ooint  of  contact  between  MTS  and  user 
programs  is  the  software  interface  which  multiplexes  the 
hardware  resources  of  the  Sycor  440.  In  the  implementation 
of  MTS  all  those  procedures  and  routines  which  provide  this 
resource  management  were  consolidated  into  a  sinale  code 
segment  called  the  service  module.  Once  again,  cue  to  the 
module  size  limitation  imposed  by  the  ML80  compiler,  it  was 
necessary  to  divide  the  service  module  into  three  physical 
submodu 1 es . 

1.   User  Interface  Submodu le 

Section  IV. D  describes  in  detail  the  form  of  a  call 
to  the  MTS  service  module.  The  implementation  of  this 
calling  protocal  follows  the  PL/M  convention  for  parameter 
passing.  That  is,  the  function  identifier  (a  single  b  v  t  ^  )  is 
passed  in  register  C ,  while  the  parameter  list  audress  is 
passed  in  register  pair  DE.  The  service  module  subsequently 
uses  the  A  register  to  pass  the  return  value  back  to  fhe 
calling  program.  A  user  program  accesses  the  service  module 
by  loading  the  C ,  D ,  and  E  registers  with  the  aporopriate 
values  and  then  executing  a  call  to  location  20D0H. 

The  service  module  provides  an  alternate  entry  noint 
for  service  requests  from  other  MTS  routines.  This 
alternate  entry  ooint  was  found  necessary  in  order  to 
implement  the  MCP  as  a  swaopaole  imaae.  Since  a  second 
entry  point  was  required,  it  was  dec i aed  to  make  the 
interface   as  general  as  possible  by  usina  neaative  function 
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identifiers  for  internal  service  calls.  This  made  it 
relatively  simole  to  verify  the  source  of  the  service 
request*  and/  as  an  added  benefit;  made  available  an  entir° 
new  series  of  function  identifiers  without  disrupt  inn  the 
series  already  in  use  for  external  calls. 

The  first  action  taken  by  the  interface  sub module 
uoon  entry  is  setting  the  software  lock  which  suppresses 
swaDpinq.  The  routine  continues  with  validation  of  the 
function  identifier  and  a  call  to  one  of  the  other 
submodules  to  handle  the  operation  reouested.  When  control 
is  regained  by  the  interface  submodule  the  swap  lock  is 
reset  and  control  returned  to  the  callina  routine. 

<? .   Service  Call  Submodule 

The  first  stec  in  the  implementation  of  the  virtual 
I/O  functions  was  to  determine  the  operations  performed  bv 
each  device.  Since  it  had  alreadv  been  decided  to  limit  the 
scooe  of  this  baseline  system,  only  three  devices  were 
considered:  terminals/  the  printer/  and  virtual  floppy 
disks  sharing  the  mini-disk.  A  total  of  ten  operations  were 
identified  as  necessary  to  provide  virtual  I/O  with  these 
three  devices.  Subsequent  efforts  concentrated  on  the 
terminals  and  virtual  floppy  disks.  Data  structures  were 
developed  to  support  each  device  and  routines  written  to 
simulate  the  operations  performed  bv  each.  To  conform  with 
the  modular  approach  adopted  for  this  project/  the  terminal 
routines  were  incorporated  in  the  terminal  interface  module. 
The   service  call  submodule  contains  the  remainina  routines. 
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Appendix  A  contains  a  detailed  descriotion  of   each   service 
call. 

3.   System  Call  Submodule 

MTS  was  designed  to  allow  each  user  a  certain  amount 
of  flexibility  in  the  virtual  environment  provided  by  the 
system.  In  order  to  implement  this  feature  it  was  necessary 
to  orovide  additional  service  routines  to  handle  this  higher 
level  resource  manaaement.  These  additional  routines/ 
called  system  calls,  are  utilized  by  the  M C P  to  satisfy 
terminal  reauests  for  changes  in  a  user's  environment.  It 
was  decided  that  these  same  services  should  also  be  provided 
to  user  programs.  This  led  to  the  inclusion  of  system  c  a  U  s 
in  the  service  module. 

The  system  calls  affect  changes  in  a  user's  virtual 
environment  by  acting  directly  on  the  status  variables 
contained  in  the  SSB.  Normally*  two  or  more  parameters  are 
reguired  to  soecify  exactly  the  action  desired.  Each 
parameter  is  examined  closely  by  one  of  several  validation 
procedures  contained  in  the  system  call  submodule.  Every 
effort  is  made  to  ensure  that  the  request  is  compatible  with 
the  current  system  state  before  any  chanqes  are  made  in  the 
SSB. 
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E.   MTS  COMMAND  PROCESSOR  MODULE 

The  MTS  command  processor  (MCP)  was  designed  to  be  a 
completely  independent  module  of  MTS  (see  I V  .  E  .  1  )  .  Th<=> 
decision  was  made  to  implement  v  C  P  utilizing  a  high-level 
language^  namely  PL/M.  This  approach  had  the  followina 
advant  ages : 

(1)  Use  of  the  PL/M  structured  constructs?  deb u going  and 
self-document i no  facilities  to  assist  in  the  raoid 
development*  checkout  and  integration  of  the  command 
processor . 
(?)  Assistance  in  simolifving  future  maintenance  and  modi- 
fication tasks  associated  with  the  command  processor. 
(3)  Provided  a  PL/M  prooram  which  illustrates  and  tests 
the  system  and  service  call  interface  reouiremer.  ts  of 
a  proqram  with  ^TS. 

Since  the  MCP  interface  did  not  reouire  direct  access  to 
the  machine  resources*  the  inefficiency  of  code  generation 
resulting  from  the  use  of  a  high-level  1 anauage  was 
outweighed  by  the  advantaaes  it  provided. 

1 .   Data  St  rue t ures 

The  data  structures  required  for  a  command  processor 
are  fairly  common/  dependino  on  the  number  and  complexify  of 
commands  available  to  the  user.  Those  used  bv  MCP  include: 
a  64  byte  command  buffer?  a  command  buffer  pointer  to  top 
next  character;  lenath  of  the  input  command  sequence?  a  bvte 
vector   to   hold   and  transfer  the  command  parameters  to  the 
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service  modu 1 e . 

The  MTS/MCP  interface  is  through  the  internal 
interface  oort  located  at  1F00H.  The  data  structures 
required  to  generate  the  function  call  interface  are 
identical  to  those  used  by  CP/M  r^l .  An  example  of  the 
calling  procedures  can  be  found  in  section  F.a  of  Appendix 
A.  MCP  is  also  required  to  save  the  fViT3  system  stac< 
pointer  prior  to  processing  the  command.  To  maintain  its 
independence*  MCP  utilizes  its  own  stack  for  internal 
processing.  It  then  restores  the  system  stack  Dointer  nricr 
to  exit.  This  ensures  a  proper  return  to  the  location  in 
the  MTS  monitor  where  MCP  was  initially  called. 

2.   Command  Process ina 

The  command  processor  is  called  bv  the  MTS  rronitor 
to  process  a  system  command  entered  by  the  terminal  user. 
After  saving  the  {ystem  stack  pointer  ana  setting  uo  its  own 
stack*  the  data  structures  are  initialized.  The  svste^ 
command  is  then  read  into  the  command  buffer  using  a 
sequence  of  MTS  service  calls.  If  the  command  buffer  is 
empty*  no  further  processing  is  accomD 1 i shed/  MCP  returns  to 
the  monitor.  Assuming  there  is  a  command  to  process/  the 
first  non-blank  character  of  the  commanH  is  read.  All  other 
characters  in  the  command  name  are  ignored  by  MCP  since  the 
first  character  of  each  command  is  uninue.  If  the  first 
character  is  not  one  of  the  valid  system  commands/  an 
INVALID  CMD  messaoe  is  sent  to  the  service  module  for 
display  on  the  aDoropriate  terminal's  status  line.   If  it  is 
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a   valid   command   character/   orocessing   of   the    command 
sequence  continues. 

Each  command  is  processed  by  its  own  subroutine. 
Validation  of  the  parameter  sequence  and  syntax  is 
accomolished  for  each  input  command  (see  D . 3 ,  Appendix  A). 
An  INVALID  C  M  D  error  message  is  displayed  for  any  detected 
error  in  syntax.  The  followinq  conversions  of  incut 
parameter  values  are  performed: 

(1)  drive  letter  -  range  of  values  is  A-H;  the  ASCII 
letter  character  is  converted  to  a  binary  number 
between  0  and  7  (e.a.  A  =  0,  6=1,  etc.). 

(2)  disk  number  -  since  the  ranae  of  values  is  from  0-31, 
no  more  than  two  characters  mav  be  entered  for  this 
parameter?  the  input  ASCII  numeric  characters  are 
converted  to  the  equivalent  binary  value. 

(  3 )  memory  size  -  ranoe  of  values  is  0  -  'J  8 ,  thus  uo  fo  two 
ASCII  numeric  characters  are  converted  t o  the 
equivalent  binary  value. 

As  the  parameters  are  processed,  each  is  saved  in 
the  parameter  vector.  After  the  command  sequence  has  been 
interpreted,  MCP  calls  the  MTS  service  module  to  continue 
processinq  the  command  request.  This  call  includes  the 
appropriate  system  command  number  and  the  parameter  or  list 
of  parameters  required  by  the  syntax  of  the  command.  The 
MTS  service  module  will  always  return  a  completion  code  to 
the  callinq  routine.  MCP  is  implemented  to  immediately 
return  this  completion  code  to  the   service   module   in   the 
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form  of  a  DISPLAY  MSG  system  call.  This  results  in  the 
aoprooriate  messaoe  heina  displayed  to  the  user  udoh 
completion  of  command  processinn  (see  E.3,  Aooendix  A).  MCP 
then  restores  the  system  stack  and  returns  control  to  the 
M T  S  monitor. 

F.   TERMINAL  INTEPFACE  MODULE 

The  terminal  interface  module  was  designed  and 
implemented  to  orovide  all  functions  and  facilities  required 
to  interface  the  four  Sycor  4  4  0  display  terminals  with  the 
remainder  of  WTS.  It  isolates  all  the  terminal  functions 
and  data  structures  into  one  independent  module.  There  ar^ 
no  external  routines  accessed  and  onlv  two  ■'  T S  alocal  data 
structures  accessed  bv  the  terminal  moaulp.  This  crovi^es  => 
high  degree  of  mocule  indeoendence  and  minimizes  thp 
external  linkage  reau i remen t s  . 

The  terminal  interface  module  Drovides  three  aene^al 
services  for  the  Sycor  440/VTS  environment: 

(1)  terminal  orimitive  functions  -  These  are  functions 
which  are  commonly  provided  by  the  terminal  hardware 
of  intelligent  text  display  devices.  However,  the 
Sycor  440  requires  that  they  b*3  provided  bv  the 
software.  These  include  such  tasks  as  converting  from 
a  keyboard  matrix  code  to  ASCII  code  for  inout  data, 
blinking  and  updating  the  current  oosition  indicator 
(cursor),  and  scrolling  the  disolay. 

(2)  input  key  processing  -  this  is  processing   done   under 
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interrupt  control*  for  each  key  activation  interrupt 
received.  It  includes  checkina  for  cac i t a  1  i zat i on  of 
alphabetic  character*  checkinq  for  any  special  M  T  S 
command  keys  and  input  character  echoina. 
( 3 )  system  interface  functions  -  these  functions  provide 
the  primary  interface  point  between  the  terminal 
module  and  other  MTS  modules.  They  provide  the 
processing  of  requests  from  ,j1TS  routines  for  terminal 
I/O  or  status  information. 

The  terminal  interface  module  was  logically  and 
physically  divided  into  five  ( 5 )  submodules.  Each  submooule 
contains  the  linkage  and  macro  definitions  necessary  to 
interface  with  other  terminal  submodules  and  Global  svstem 
data  structures  as  required.  The  oassino  of  parameters 
between  procedures  and  submodules  within  the  terminal  moaule 
is  accomplished  entirely  through  the  machine  reoisters.  The 
terminal  interface  submodules  are  discussed  in  *•  ^  e  f  o 1 1 o  w  i  n  o 
paragraphs . 

1  .   Data  St  rue  t  ures 

This  submodule  provides  all  the  internal  data 
structures  used  by  the  terminal  interface  routines.  An 
important  point  to  keep  in  mind  is  that  a'l  data  structures 
providing  display  I/O  control  are  in  multioles  of  f  o  u  r  r 
reguiring  one  for  each  of  the  four  terminals.  Fach  terminal 
was  assigned  an  identification  number  f ro"  0-3. 

The  primary  data  structures  providina  display  T/0 
control   include   the  four  S76  byte  D^A  buffers  discussed  in 
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section  IV. F. 2  and  the  followina: 

(1)  disolay  base  -  a  data  vector  containing  the  base 
address  of  each  of  the  512  byte  display  buffers  (ones 
not  include  the  64  byte  status  line). 

(2)  cursor  -  a  pointer  specifying  the  current  display 
address  (from  0-511)  at  which  the  cursor  character  is 
to  be  disolayed. 

( 3 )  current  line  -  a  oo  inter  soeci^yina  t^e  initial 
display  address  of  the  current  line  in  which  the  user 
is  enterinq  data.  This  line  has  not  yet  heen 
terminated  by  a  line  termination  key  (see  section 
IV. F. 2) . 

( 4 )  next  char  -  a  pointer  soecifying  the  initial  displav 
address  containing  the  next  character  in  the  inout 
line  (buffer)  to  be  processed.  An  incut"  line  is 
defined  as  a  strino  of  up  to  512  ASCII  characters 
which  has  been  terminated  by  a  line  termination  key. 

(5)  end  ibuff  -  end  of  the  inout  buffer;  points  to  the 
display  address  where  a  line  termination  key  was 
rece  i  ved . 

(6)  terminal  status  -  contains  the  current  status  of  each 
terminal's  inout  buffer;  the  possible  values  are  innut 
waiting*  M  T  S  cmd  ready*  or  ibuff  errnty. 

Additional  data  structures  include:   a   matrix  coae 

to   ASCII  conversion  table;  an  upper  or  1  <~>  w  e  r  case  kev  entry 

mooe  indicator;  status  line  base  address   vector;   and  data 
vectors  containing  status  line  messages. 
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2.  Utility  Rout  i  nes 

This  submodule  contains  the  basic  utility  routines 
which  provide  common  register  manipulation  and  processinn 
required  by  the  remaining  terminal  submodu 1 es .  The  on] v 
data  structure  needed  by  this  submodule  is  a  swap  position 
address  used  for  swap  cursor  procession.  These  utility 
functions  include:  comoarinq  display  pointers  to  determine 
if  they  are  e  a  u  a  1  ?  converting  a  binary  number  to  an  A  S  r  1 T 
display  code/  getting  and  storing  display  characters;  mnv/inn 
bytes  of  data  from  a  memory  source  to  a  "^mory  destination? 
and  swapping  the  current  cursor  position  character  with  the 
swap  position  character.  This  is  the  basic  mechanism  used 
to  provide  the  blinking  cursor  feature. 

3.  Terminal  Interface  Primitives 

This  submodule  contains  the  routines  which  rrovide 
the  primitive  functions  of  the  terminal  mooule.  "These 
procedures  require  linkages  to  all  the  display  control  data 
structures  and  the  status  base  adcess  vector.  The 
primitive  functions  include!  blank  inn  a  soecified  area  in 
the  display  buffer;  retrieving  appropriate  disclay  buffer 
and  status  line  addresses;  returnina  the  current  terminal 
status?  sending  beeo  and  click  alerts  tc  terminals? 
scrolling  a  specified  terminal's  display;  and  updatina  the 
current  cursor  Dositicn. 
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4.   Key  Processina  Routines 

This  submodule  provides  one  of  the  basic  functions 
of  the  terminal  module,  that  of  processing  each  key 
character  entered  at  a  terminal.  It  reauires  linkage  to 
most  of  the  terminal  data  structures  and  to  one  global 
system  data  structure*  the  task  status  contained  in  the  SS6. 
A  bit  is  set  in  the  task  status  byte  when  an  MTS  svstem 
command  is  entered  at  a  terminal.  This  submodule  is  called 
by  the  terminal  interrupt  handler  to  nrocess  the  incut  i^ey 
code.  The  following  is  a  summary  o  *  the  procession 
accomplished:  convertina  the  input  matrix  code  to  the 
appropriate  ASCII  code?  checkina  for  and  converting  lower  to 
upper  case  letters  if  reouired/  checking  for  any  key 
commands  (including  all  line  editina);  a^a  if  not  a  kev 
command/  the  input  character  is  echoed  r  =>  c  k  to  the  terminal 
display.   A  key  command  is  one  of  the  following: 

(1)  line  termination  key  -  either  an  E^RQR  RESET  or  CR 
key.  Checks  to  see  if  input  can  be  accented.  If 
input  is  already  waiting  to  be  processed  the 
termination  key  is  not  accepted  and  a  terminal  been 
alert  is  sent  to  the  terminal.  Otherwise  the  current 
line  is  established  as  the  new  input  buffer.  The 
appropriate  terminal  status  is  set  and  if  it  is  an  MTS 
command*  the  WCP  bit  in  the  task  status  bvte  is  set. 
This  ensures  that  the  command  processor  is  called  dv- 
the  monitor  to  process  this  commano. 

(2)  line  editing  and    cursor  control  kevs   -   provides   the 
processing   for   character   delete*  line  delete/  clear 
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screen*  and  move  cursor  left  or  right.   Terminal   b  e  e  d 
alerts   are   aenerated   if   the   function   can   not  ho 
performed. 
(3)  entry  mode  key  -  sets  or  clears  the  current  alphabetic 
key  entry  to  the  appropriate  uDoer  or  low^r  case  to^e. 

5.   System  Interface  Functions 

This  submodule  contains  the  routines  which  rrovi'Je 
the  terminal  module  interface  with  the  rest  of  the  M T S 
modules.  It  provides  readinq  and  writina  o  f  characters  f»-om 
or  to  the  terminal  disolav  buffers*  terminal  status 
information  ( e  .  q  .  whether  or  not  there  is  input  wait! no) J 
display  of  status  and  w  T  S  messaqes  on  the  terminal  status 
line'  control  of  the  periodic  blinkina  of  the  display  cursor 
character*  and  cl earing  the  status  line  when  reauested. 
This  submodule  links  to  the  terminal  data  structures  and  to 
a  global  system  variable  which  always  soeci^ies  the  terminal 
number  associated  with  the  function  request. 
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VI.   CONCLUSIONS  AND  RECOMMENDATIONS 


The  primary  goal  of  this  thesis  project  was  to  determine 
the  most  feasible  method  of  inteqrating  the  Svcor  4  4  0  system 
into  the  facilities  of  the  MPS  microcomputer  laboratory. 
The  aim  was  to  make  available  the  resources  of  the  Sycor  4 4 0 
in  support  of  microcomputer  systems  development.  T  h  e  main 
objective  was  to  orovide  an  environment  for  the  sharing  of 
these  resources  among  multiple  users.  The  Microcomputer 
Timeshared  System  was  developed  to  accomplish  this  resource 
sharing.  The  sharing  o  *  the  3080  microprocessor  through 
multiorogrammina  rather  than  multiprocessing"!  was  implemented 
only  because  of  the  hardware  configuration  of  the  Sycor 
440.  The  relatively  low  cost  of  microprocessors  would 
normally  lead  to  the  implementation  of  a  microprocessor- 
based  timeshared  system  with  dedicated  CPUs  for  each  user. 
Thus#  the  emphasis  was  placed  on  the  sharinc  reouirements  of 
the  remaining  system  resources.  The  sharing  o  *  the  Sycor 
440  memory  was  implemented  throuah  the  use  of  swapnina, 
providing  up  to  48K  of  RAM  for  user  programs.  Sharina  of 
the  mini -disk  auxiliary  storage  was  provided  throuah  the 
virtual  floppy  disk  concent. 

During  the  research  and  development  of  M  T  S  »  several 
areas  were  identified  as  potential  candidates  *  o  r 
enhancement.  These  areas  include:  enhancements  to  the 
prototype    MTS    system,   enhancements   to   the   Svcor   4  40 
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hardware*  and  ML80  enhancements. 

The  baseline  timeshared  system  as  imolemented  provides 
sharing  of  the  Syc-or  440  memory  and  mini-disk  resources 
amongst  multiple  terminal  users.  An  obvious  extension  to 
this  basic  implementation  is  the  sharing  of  the  remaining 
dedicated  I/O  devices  (e.q.  printer,  cassette,  etc.) 
provided  by  the  Sycor  440.  These  facilities  were  planned 
for  during  the  desiqn  phase  of  MTS  ana  interface  points 
provided  throuahout  the  imolemented  oaseline  system  to 
ensure  easy  inclusion  at  some  later  date.  Additional 
information  on  sucaested  desian  and  implementation 
aDproaches  for  these  features  are    contained  in  Pef.  1. 

From  the  Sycor  440/MTS  interface  point  of  view*  the  main 
enhancement  to  the  current  hardware  co^*iquration  would  oe 
the  inclusion  of  the  fast,  multi-sector  ^ini-disk  controller 
presently  under  development  at  Sycor.  To  assist  in  tne 
further  integration  of  the  Sycor  440  into  the  current- 
microcomputer  development  facilities,  the  addition  of  a 
floopy  disk  df i ve  would  be  helpful.  It  is  recommended, 
however,  that  the  floopy  disk  interface  be  an  addition  to, 
not  a  replacement  for,  the  current  cassette  interface.  The 
cassette  driver  is  necessarv  in  order  to  maintain 
comoat i b i 1 i t y  between  the  Sycor  440  and  the  340  debuaqer. 
Additional  hardware  enhancements  which  would  assist  in  the 
implement  ion  of  a  timeshared  microcomputer  system  include  a 
bounds  register*  for  memory  protection  and  a  mo^e  reqis^er 
with  interrupt  loaic  to  provide  a  dual-state  machine. 

A  secondary  objective  of   this   thesis   project   was   to 
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evaluate  the  performance  of  ML80  in  the  development  of  a 
reasonably  larqe  system.  In  aeneral#  the  use  of  ML 80 
provided  many  advantages  over  assemMv  languane  orooraTminq 
without  incurring  the  penalty  of  inefficient  code 
generation.  The  alaebraic  notation  provided  by  the  1 anouaqe 
proved  especiallv  convenient  in  working  at  the  register 
level.  The  improved  readability  of  the  source  code  was  o  * 
great  assistance  during  the  development  of  "-1  T  S .  The  ot^er 
features  of  ML 80  discussed  in  section  IV.G  Droved/  for  tn<* 
most  partr  <"o  be  very  satisfactory.  wowever,  as  described 
in  chaDter  V,  the  relatively  small  amount  of  m  p  m  o  r  v 
available  on  the  s  v  s  f  e  m  which  hosted  the  c  o  m  d  i  1  p  r  caused 
numerous  problems.  To  Drovide  a  completely  adeauatp 
environment  for  the  development  of  larger  systems/  a 
necessary  improvement  would  be  the  modification  of  ML80  to 
run  on  a  system  with  more  memory  available  for  tables  and 
stacks.  An  obvious  method  of  imDlementino  this  imorovement 
is  to  enlarge  ^  L  8  0  '  s  fixed  size  stacks  and  run  the  compiler 
under  the  version  of  CP/M  modified  for  the  Sycor  4  4  0  / f/  T  S 
environment.  Additional  suoqestions  for  enhancements  to 
ML80  include:  addinq  a  macro  library  capability  for  ease  of 
implementino  common  macros/  modifyina  EXTERNAL  and  COMMON 
declarations  to  provide  linkage  to  individual  identifiers 
rather  than  entire  modules  as  is  now  doner  and  outnuf t ina 
compiler  error  messaoes  and  svmbol  table  listinqs  to  a  orint 
file  for  easier  debuqqinq. 
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APPENDIX  A     MTS  USER'S  MANUAL 


The  pumose  of  this  document  is  to  provide  the  user  with 
the  information  necessary  to  utilize  the  Microcomputer 
Timeshared  System  (MTS).  The  contents  include  information  on 
setting  up  the  Svcor  440  System  for  use  with  M T S »  loadinq 
and  initializina  M  T  S ,  and  interfacing  with  the  MTS  operation 
system.  Sections  A  and  B  provide  a  qpnpral  description  of 
MTS  design  concepts  and  the  Svcor  4  4  0  System.  Section  C 
provides  the  detailed  information  necessary  to  interface  the 
Svcor  440  System  and  ^TS.  Section  0  contains  information  on 
the  terminal  desian,  key  functions^  and  svstem  commands 
which  enable  the  terminal  user  to  communicate  with  MTS. 
Section  E  describes  the  MTS  status  line  display  and  defines 
the  various  messaaes  displayed  by  MTS.  Section  F  details 
the  services  provided  a  user  oroaram  by  M  T  S  r  and  the 
limitations  on  a  user  program  running  in  the  MTS 
environment.  For  more  detailed  information  on  operatina 
procedures  for  the  Sycor  440  System  consult  section  G,  Ref. 
2.  The  complete  MTS  desian  specification  and  implementation 
information  is  contained  in  Ref.  1. 
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A.   MTS  CONCEPTS  AND  DEFINITIONS 

The  acquisition  of  the  Sycor  440  Clustered  Terminal 
Processing  System  provided  an  opportunity  for  development  of 
a  shared  environment  for  microcomputer  research  and 
development.  In  response?  the  Microcomputer  Timeshared 
System  (MTS)  was  desioned  and  built  to  ornvide  the  basic 
machine  interface  and  system  manaaement  functions  necessary 
for  a  shared  environment. 

The  purpose  of  f/TS  is  to  orovide  an  interface  between 
the  bare  Sycor  440  machine  and  up  to  four  user  tasks 
executing  concurrently.  The  MTS  environment  as  viewed  bv 
the  user,  provides  all  the  microprocessor  facilities 
reguired  for  microcomputer  research  and  develnoment.  Fro"  a 
system  point  of  view,  ^  T  S  ^anaoes  the  available  hardware  to 
ensure  that  the  hardware  resources  are  eguitablv  and 
efficiently  allocated  to  competing  user  programs.  MTS  is 
designed  to  interface  with  a  version  of  CP/^  modified  to  run 
on  the  Sycor  440.  This  enables  all  systems  and  pronrams 
designed  to  run  with  the  CP/M  operating  system  to  run  on  the 
Sycor  440  with  minor  modifications  (such  as  a  change  in  load 
address).  This  includes  all  the  development  facilities 
available  with  CP/M,  such  as  the  context  editor*  dynamic 
debugaer,  assembler,  etc.  Reference  1  contains  a  list  of 
references  for  CP/M  and  its  facilities. 
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b.  sycor  aao  hardware  description 

The  Sycor  440  Clustered  Terminal  Processing  System  at 
NPS  is  composed  of  a  control  unit  containino  a  cassette  tape 
driven  four  disclay  terminals*  a  Centronix  matrix  printer, 
and  a  Svcor  Model  3^0  Communications  Terminal. 

The  control  unit  is  the  heart  of  the  4  4  0  system. 
Contained  within  a  waist-hiah  cabinet  are  random  and  control 
logic  including  two  8^80  chips*  6  4  K  of  random  access  memory 
(RAM),  interfaces  for  all  peripheral  devices,  a  five 
megabyte  fixed  disk,  as  well  as  the  aforementioned  cassette 
tape  drive. 

Located  together  on  the  front  of  the  control  unit  are  an 
QN/OFF/PESET  keylock  and  system  status  panel.  Turninn  the 
keylock  to  the  RESET  nosi  t  ion  activates  a  diagnostic 
bootstrap  orogram  located  in  read-only  memory  (ROM).  This 
bootstrap  proaram  performs  several  diagnostic  tests  on  the 
CPU,  memory,  and  system  load  device  (cassette  or  mini-Hisx:) 
and  then  initiates  system  loadina.  fhe  status  of  the 
diaanostic  tests  is  indicated  bv  a  series  of  red  lights  on 
the  system  status  panel.  These  liahts  are  turned  off  in 
seguence  as  each  phase  of  the  test  is  successfully 
completed.  When  all  red  liahts  have  been  turned  off/  three 
green  lights  on  the  panel  will  remain  lit  to  indicate  that 
all  power  supplies  ar^  functioning  normally.  There  is  also 
one  additional  red  light  at  the  bottom  of  the  system  status 
panel  which  only  comes  on  if  the  temoerature  inside  the 
control  unit  cabinet  exceeds  normal  ODerating  limits. 
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One  of  the  two  8080  chips  located  in  the  440  control 
unit  serves  as  the  system  CPU.  The  8060  instruction  set 
consists  of  the  7*  data  transfer/  arithmetic/  logical/ 
branch/  stack/  1/0/  and  machine  control  instructions 
described  in  Ref.  3.  The  Sycor  440  provides  a  comprehensive 
set  of  prior itizea  interrupts  includino  a  Hier»  peripheral 
device/  and  auxiliary  storaae  device  interrupts.  Passina 
control  information  and  data  between  the  R0K0  CPU  and 
peripheral  devices  is  accomplished  by  utilizing  the  T/P 
ports  (called  latches  in  Sycor  literature!  provided  on  <■  h  e 
8080  chip. 

The  second  80^0  chip  found  in  the  control  unit  acts  as  a 
controller  for  the  mini -disk.  The  mini-disk  is  a  sin ale 
platter/  movable  head/  fixed  disk  blocked  into  SI?  Dvt«=> 
sectors.  There  are  800  tracks  on  the  aisk  with  1"^  sectors 
per  track.  Oata  transfer  between  RAM  and  the  mini-disk  is 
via  direct  memory  access  (DMA).  The  mini-disk  controller 
communicates  with  the  host  8080  CPU  throuah  a  13  bvte  disk 
control  block  (OCR)  located  at  a  fixed  location  in  memory. 

Peripherals  supported  bv  the  Sycor  440  system  include 
bisynchronous  and  asynchronous  communication  devices/  up  to 
eight  display  terminals/  serial  and  line  printers/  and  card 
readers.  The  NPS  conf i aurat i on  has  four  display  terminals 
consisting  of  a  typewrit-er-like  keyboard  and  CRT  displav 
device.  Each  terminal  disolavs  a  DMA  image  of  a  576  byte 
terminal  buffer  located  in  RAM.  Keyboard  input  is 
accomplished  by  software  translation  of  a  keyboard  matrix 
code  into   the   cor respondi nq   ASCII   character   code.    Por 
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hardcooy  output  the  NPS   440   includes   a   Centronix   sprial 
matrix  printer. 

Several  different  auxiliary  storaqe  devices  may  op 
attached  to  the  Sycor  440  in  addition  to  the  mini-disk. 
These  include  maqnetic  tape  drives*  cassette  taoe  drives* 
and  floopy  disk  drives.  The  NPS  confiquration  includes  a 
cassette  taoe  drive  located  in  the  control  unit.  This  drive 
provides  compatibility  between  the  Sycor  440  system  and  the 
Model  340  debuqqer. 

The  Model  340  Communications  Terminal  is  a  complete 
system  in  its  own  riqht  which  is  marketed  by  Sycor  for 
remote  job  entrv  (RJE)  applications  [4],  When  utilized  as  a 
hardware  debuqger*  the  340  is  auqmenteo  with  4K  of  RAM  and  a 
backplane  couplinq  to  a  special  wire-wrapoed  interface  board 
in  the  440  control  unit.  The  340  debuager  is  provided  with 
a  software  package  which  includes  provisions  for  loadina  and 
dumping  hex  format  croqram  files  between  cassette  tape  and 
440  RAM,  examination  and  modification  of  individual 
locations  in  440  memory*  insertinq  breakpoints  and  traps  in 
programs  executina  on  the  440,  and  s i nql e-s t eop i nq  through  a 
program  executing  one  instruction  at  a  time  [6J . 

There  are    several  hardware  characteristics  of  the   Sycor 
440   system   which  stronqly  influenced  the  implementation  of 
MTS.   The  most  important  of  these  are: 
(1)  8080  CPU  architecture 
( <? )  terminal  desiqn 

(3)  mini-disk  interface 

(4)  single-state  CPU 
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(5)  lack  of  memorv  protection 

A. 

The  impact  which  each  characteristic  had  on  the  desian  and 
implementation  of  MTS  is  covered  in  Ref.  1.  For  a  more 
detailed  discussion  of  Sycor  440  hardware  characteristics 
see  Ref .  ? . 
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C.   SYCOR  440/MTS  INTERFACE 

The  Microcomputer  Timeshared  System  was  desiqned  and 
built  for  use  on  thp  Sycor  4  4  0  Clustered  Terminal  Process i no 
System.  For  this  reason  MTS  depends  heavily  on  specific 
features  of  the  Sycor  implementation  of  an  8080  base') 
microprocessor.  This  dependence  includes  reliance  on  Sycor 
supplied  software  as  well  as  the  4  4  0  hardware?  but  becomes 
most  apparent  to  the  user  in  the  two  areas  of  loaHina  the 
system  and  maintainino  system  files. 

1.   Loadinq  the  System 

The  MTS  object"  module  resides  on  the  rr  i  n  i  -  a  i  s  k  in  a 
relocatable  format  acceotable  to  the  Svcor  System  Loader. 
The  System  Loader  is  called  in  to  memory  D  y  setting  the 
internal  system  definition  switch  to  3  and  tumino  the 
ON/OFF/RESET  keylock  on  t*e  control  unit  to  the  RESET 
position.  After  MTS  is  loaded  execution  begins  with  the 
initial  proaram  load  (TPL)  module.  The  query  REC0VERY? 
(Y/M)  is  displayed  at  terminal  0.  The  operator  should  enter 
Y  if  recovery  is  desired*  otherwise  N.  In  the  event  that 
the  IPL  operation  is  halted  due  to  a  file  access  error  (file 
non-existent  or  cannot  be  read)  the  message  IPL  ABORTED 
followed  by  a  system  file  name  will  apce^r  at  terminal  0. 
After  correctino  the  problem  the  operator  may  reload  in  the 
normal  manner.  When  the  IPL  ABORTED  messaoe  is  accomp^nieH 
by  the  HARDWARE  ERROR  terminal  alert  it  indicates  thaf  an 
abnormal  comoletion  code  was  returned  by  the  mini-disk 
controller  after  a  read   operation.    Further   investigation 
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using  the  Sycor  utility  proorams   FIX  MAR   or   ..ZAP   m  a  v   be 
required  to  identify  the  problem  [2,51. 

To  summarize,  loadinq   MJS   involves   the   followinq 
steps : 

(1)  set  internal  system  definition  switch  to  3 

(2)  turn  ON/OFF/RESET  keylock  to  RESET 

(3)  wait  two  minutes  while  mini-disk  reaches  ooeratino 
speed  and  all  red  liahts  on  control  unit  Status  nanel 
go  out 

(4)  respond  to  DECOVERY?  query  with  iNJ  to  initialize  a  new 
system  or  Y  to  recover  from  the  last  ooeratinq 
session. 


2.   Recovery  File  -  .MTSRCVR 

MTS  supports  limited  recovery  after  a  user  task 
causes  a  system  crash.  T  h  p  recovery  feature  is  implemented 
by  copying  the  contents  of  the  system  state  block  (SSBl 
after  each  swap  to  a  mini-disk  file  known  as  the  recovery 
file.  Since  the  SSB  defines  the  state  of  the  system  at  anv 
instant/  recovery  may  be  accomplished  by  reload inq  the  SSB 
from  the  recovery  file/  deletinq  the  task  causinq  the  crash/ 
and  proceeding  with  normal  execution.  These  actions  are 
performed  bv  the  MTS  TPL  module  when  the  answer  to  the 
RECOVERY?  guery  is  Y. 

Whenever  MTS  is  runninq,  a  sinqle-sector  file  named 
.MTSRCVR  must  be  listed  in  the  mini-disk  directory.  In  tne 
event  this  file  is  deleted/  it  may  be  recreated  under  the 
Sycor  operatinq  system  by  using  the  command 


CREATE  .MTSRCVR  N=l 
The  contents  of  the  recovery  file  at  the  comoletion  o*  an 
operating  session  are  only  meaningful  if  recovery  will  be 
requested  when  MTS  is  next  loaded.  Therefore*  under  normal 
circumstances  this  file  is  not  needed  when  MTS  is  not 
runn  i  nq. 

3.   Swao  Files  -  .MTSSWPx 

One  of  the  most  fundamental  requirements  on  anv 
timesharing  system  is  maintainina  independence  nf  user  tasks 
executing  concurrently.  MTS  satisfies  this  reouirement  by 
maintaining  physical  as  well  as  logical  separation  of  all 
user  tasks  in  the  system.  ^ssociatea  with  each  of  the  four 
terminal  tasks  is  a  mini-disk  file  used  to  store  a  core- 
image  of  the  task  when  it  is  wait  i  no  for  the  CPU  or  Mocked 
pending  some  I/O  operation.  At  any  given  instant  a  task  may 
reside  on  the  disk  in  its  swao  file  or  in  memory*  but  a+  no 
time  can  two  or  more  tasks  reside  in  memory  simultaneously. 

A  task's  swap  imaae  consists  of  17  bytes  reserved  by 
MTS  for  environment  and  virtual  device  control  data  followed 
by  up  to  48,896  bytes  of  user  task  memory  imaae.  Thus,  the 
maximum  allowable  swao  image  is  aoprox i mat e 1 y  4KK  byt^s. 
There  is  no  minimum  value  for  the  size  of  a  swap  image.  The 
swap  image  size  or,  ecu i va 1 ent 1 y t  the  amount  of  memory  space 
available  to  the  user  is  variable  from  0  to  U^K.  In  fact, 
the  user  is  encouraged  to  use  the  smallest  swao  image  which 
satisfies  his  reguirements  as  smaller  swao  images  tend  to 
improve  system  resoons i veness . 
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A  48K  swao  imaqe  will  fill  96  sectors  on  the  mini- 
disk. Therefore  each  of  the  four  swao  files  should  normal lv 
be  96  sectors  lonq.  In  the  event  that  mini -disk  space  is 
limited*  or  that  user  tasks  do  not  rpqure  a  4  8  K  swap  imaoe» 
MTS  will  automatically  adjust  to  any  file  size  qreafer  than 
16K  (32  sectors).  Sixteen  kilobytes  was  selected  as  the 
minimum  and  default  system  size  since  it  provides  a 
reasonable  amount  of  memory  for  runninq  the  C P / M  operatina 
svstem.  The  I  PL  module'  performs  a  size  test  on  each  swao 
file  to  ensure  that  it  is  at  least  3  2  sectors  lonn.  '^TS 
cannot  be  loaded  if  any  swao  file  is  smaller  than  32 
sectors . 

If  it  becomes  necessary  to  chanoe  the  size  of  any  or 
all  swaD  files?  the  file(s)  must  first  be  oeleted  from  the 
mini-disk  directory.  This  is  accomplished  under  the  Fycor 
operating  system  usinc  the  command 

DELETE  <f i lename> 
where  <filename>  may  be   .MTSS/jPO,   .MTSSWP1,   .MTSSWP2,   or 
.MTSSWP3.   The   number   in   each  case  indicates  the  terminal 
with  which  the  file  is  associated.   After  the  file  has   been 
deleted?  it  may  be  recreated  by  using  the  command 

CREATE  <filename>  N  =  96 
for  each  file  which  has  been  deleted.   If  swao  files  smaller 
than   4  8  K  are    desired?  the  value  o f .  N  in  the  CREATE  command 
string  should  be  two  times   the   reauired   memory   spac1   in 
kilooytes?  but  no  less  than  32. 

The  contents  of  the  swao  files  uoon  completion  of  an 
MTS   operatinq   session  are  only  meaningful  if  recovery  *  i  11 
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be  requested  when  ^TS  is  next  loaded.  Under  normal 
circumstances  these  four  files  are  not  required  when  M  T  S  is 
not  runn i  ng . 

a.   Conf iaurat i on  File  -  .MTSCNFG 

As  exolained  in  section  A . 2 • c ,  ^  T  S  identifies 
virtual  floppy  disks  by  a  logical  disk  number  ranaing  from  0 
to  31.  Since  each  virtual  floppy  disk  actually  resides  in  a 
mini-disk  file  created  under  the  Sycor  operatino  system^ 
there  must  be  some  mechanism  for  maopino  a  loaical  disk 
number  into  a  file  name  contained  in  the  mini-disk 
directory.  This  function  is  performed  by  the  configuration 
file  .MTSCNFG. 

The  confiauration  file  is  made  up  of  32  entries  o  * 
thirteen  bvtes  each  contained  on  a  sinal*3  mjoj-di  sk  sector. 
Each  entry  has  the  format 


!    FILENAME    !   KFV   ;paj 
0  7  8       1112 

where  FILENAME  is  the  0  to  8  byte  name  of  the  virtual  flonpy 
disk  file  as  it  aopears  in  the  mini-disk  directory;  KFY  is  a 
0  to  4  byte  protection  key;  PA  is  the  protection  attribute 
of  the  virtual  disk,  i.e.  'P'  for  read/write  protection,  'R' 
for  write  protection  only  (restricted  access),  and  blank  for 
no  protection.  The  loaical  disk  number  for  each  entry  is 
simply  the  position  of  that  entry  within  the  file.  For 
example,  the  first  entry  is  assioned  logical  disk  number  0, 
the  last  entry  31,  and  the  entrv  which   is   preceded   by   17 
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other  entries  becomes  number  17. 

The  configuration  file  is  read  by  M  T  S  durinq  the 
initialization  process  Derformerl  bv  the  1PL  module.  The 
filename  is  extracted  from  each  entry  and  input  to  a  routine 
which  searches  the  mini-disk  directory.  When  a  match  occurs 
the  mini-disk  address  for  the  file  is  read  from  the 
directory  and  entered  in  a  virtual  floopy  disk  map  table. 
If  no  match  occurs  for  a  aiven  configuration  file  entry,  the 
corresponding  looical  disk  number  is  marked  not  available. 
Any  subseouent  attempt  to  access  that  virtual  disk  will 
result  in  the  terminal  altert  DISK  NOT  AVAIL  CE.3). 

The  con f i ou r a t i on  filp  may  on] v  De  modified  when 
running  under  the  Sycor  operatina  system.  Svcor  provides  a 
data  entry  free  far™  mode  which  allows  the  terminal  operator 
to  examine  and  modify  the  contents  of  the  file  1 5 )  .  F  x  t  r  p  m  e 
care  must  be  exercised  when  uodatina  .MTSCNFG  to  align  each 
entry  properly  in  the  file.  ^TS  assumes  the  file  will  be  in 
the  prooer  format  when  read,  and  makes  no  attempt  to 
validate  individual  entries. 

Since  the  information  contained  in  the  configuration 
file  is  of  a  permanent  nature  and  can  only  be  recreated  with 
great  difficulty/  the  file  .MTSCNFG  should  ne\jer  be  deleted 
from  the  mini-disk  file  directory.  In  the  event  the  file  is 
deleted  erroneously,  a  new  file  may  he  created  under  tne 
Sycor  operating  system  using  the  RESTORE  command  and  a 
backup  cassette  labeled  ".MTSCNFG  DUMP".  The  command  is 
entered  as 

RUN  RESTORE  2=/CSST 
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with  .MTSCNFG  DUMP  mounted  in  the  cassette  drive.  This 
command  will  build  a  new  file  directory  entry  for  .MTSCNFG 
and  establish  a  basic  con f i aurat i on  file  with  3?  entries  of 
the  form  .DISKx,  where  x  ranqes  from  0  to  31.  This  basic 
file  may  then  be  edited  as  described  above  to  reflect 
current  file  names  and  protection  attributes. 

5.   Virtual  Floppy  Disk  Files 

Each  virtual  floppy  disk  resides  on  a  block  of 
logically  contiguous  mini-disk  sectors.  This  block  must  be 
allocated  usina  the  facilities  provided  by  the  Sycor 
operating  system,  specifically  th°  command 

CREATE  <filename>  N=<file  size> 
where  <fi1ename>  is  a  1  to  6  character  na^e  to  be  entered  in 
the  "nni-disk  directory  and  configuration  filer  and  <  f  i  1  » 
size>  is  the  length  of  the  file  in  512  byte  mini-disk 
sectors.  For  the  standard  2  5  6  K  bvte  floppy  disk  <  f  i  1  e  s  i  z  e  > 
eouals  512,  i.e.  (256  *  1024)/512=512. 

Where  a  physical  floppy  disk  has  a  fixed  capacity  o  * 
256K  bytes,  an  MTS  virtual  disk  may  have  any  convenient 
size.  MTS  assumes  that  the  disk  image  is  made  up  of 
contiguous  128  byte  floppy  disk  sectors  starting  with  track 
0  sector  1/  proceedino  throuah  the  26  sectors  of  track  0  to 
track  1  sector  I,  and  so  on  until  the  virtual  disk  file  is 
full.  If  the  virtual  cisk  file  size  is  less  than  512  mini- 
disk sectors*  less  than  77  floppy  disk  tracks  will  be 
addressable.  Conversely,  if  the  file  size  exceeds  51?,  then 
more   than  77  tracks  will  be  addressable?  up  to  a  maximum  of 
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256  tracks.  In  either  case  MTS  automatical ly  adjusts  the 
upper  bound  based  on  the  file  size  as  shown  in  the  mini-disk 
di  rectory . 

It  is  important  to  nofe  that  ^TS  onlv  recoqnizes 
virtual  floppy  disk  files  which  are  enterea  in  the 
configuration  file.  The  logical  disk  number  associated  with 
a  given  virtual  floopv  disk  file  is  aetermined  by  that  files 
position  in  .  MTSCNFG.  When  the  file  is  initially  entered  in 
the  configuration  file  a  protection  kev  and  orotection 
attribute  should  also  be  entered,  if  desired. 
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D.   MTS/USER  TERMINAL  INTFRFACE 

1.   Terminal  Interface  Design 

The  general  format  of  each  terminal   display   is   as 
f ol 1 ows : 


J  o 

STATUS 

LINE 

63! 

!//////////////////////////////////////! 

!  0 

D 

63! 

lea 

1 

127! 

:  128 

B 

S 

191  ! 

:  19? 

U 

P 

2^5! 

1256 

F 

L 

319! 

1320 

F         A 

3*3! 

!  38U 

E 

Y 

am  ! 

|448 

R 

51  1  ! 

The  numbers  are       decimal   and   SDecify   character   positions 
within  the  status  line  and  display  buffer. 

a .   Status  Line 

The  terminal  status   line   is   used   by   VTS   to 
disolay  three  types  of  status  information: 

(1)  The  current  virtual  drive  and  floppy  disk   ass i onmen t s 
for  that  terminal. 

(2)  The  size  of  the  user's  swao  imaae*  i.e.  the  amount   of 
memory  space  currently  available. 

(3)  Error  message  alerts  produced  by  M  T  S  system   commands* 
or   resulting   from   user  proa  ram  calls  on  the  DISPLAY 
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MSG  service  routine  (see  F . ?  . )  . 

The  status  line  disDlay  format  and  contents  are 
discussed  in  detail  in  section  F. 

b.   Oi  sd 1  ay  Buf  f er 

The  disolay  buffer  can  hold  ud  to  a  maximum  of 
512  characters.  The  display  buffer  also  acts  as  an  innut 
Duffer/  holding  the  inout  data  until  the  user's  program 
reguests  it.  Due  to  the  unavoidable  delays  in  user  rroqran 
response  caused  bv  swapping  and  aoqravated  by  the  relatively 
low  data  transfer  rate  of  the  mini-disk,  the  MTS  terminal 
interface  provides  character  echo  inn  and  simple  line  edit i no 
features.  This  ensures  reasonable  resDonse  times  to  kev 
activation  by  the  user.  Thus*  input  data  can  not  be 
considered  available  to  the  user's  oroaram  until  an  input 
line  termination  character  has  been  received  hy  MT^.  To 
establish  an  inout  buffer  for  a  program/  the  user  enters  tn« 
data  and  terminates  the  line  by  hitting  the  N  E  to  1. 1 N  E  or  ENTER 
keys  on  the  keyboard.  This  establishes  that  line  as  an 
input  buffer  available  for  processing  bv  the  user's  prooram. 
Note  that  the  key  combinations  'I/O  CTL  M'  or  'SHIFT  CR' 
(on  the  number  pad)  will  also  result  in  the  termination  of 
an  inout  line.  Either  of  these  keys/  as  well  as  NEWLINE  and 
ENTER/  may  be  used  for  line  termination. 

Once  an  input  buffer  has  been  established  the 
user  may  continue  to  input  data  on  the  next  line.  The  user 
may  use  any  of  the  line  editino  or  other  cursor  control 
features   on  this  new  line  of  input  data.   However/  this  new 
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line  mav  not  be  terminated  until  the  user's  proqram  has 
processed  the  previous  input  buffer  (see  terminal  alerts 
below). 

Each  character  output  from  the  user's  prooram  is 
displayed  at  the  current  cursor  position.  Fach  output 
results  in  all  input  buffer  pointers  beino  r^set  to  the 
character  position  at  the  end  of  the  output  data.  Thus*  new 
I/O  will  start  this  point.  This  implies  that  if  trip  user 
had  been  in  the  middle  of  entering  aata  when  the  outnut 
occurred*  it  must  be  reentered. 

c.   Terminal  Alerts 

The  MTS  terminal  interface  orovioes  the  user 
with  either  a  visual  or  audio  response  to  eacn  Wev 
depression.  Normal  visual  resoonse  is  nrnvided  by  display 
of  the  entered  character  and/or  -nove^ent  of  tne  displav 
cursor.  The  display  cursor  is  a  blinlcina  underscore 
Character  which  marks  the  current  position  on  the  screen. 
Data  is  always  entered  and  displayed  at  the  current  cursor 
posi  t  i  on . 

The  audio  responses  consist  of  either  a  beep  or 
click  at  the  terminal.  A  terminal  beeo  alert  will  be 
generated  for  any  of  the  followina  conditions: 

(1)  An  input  buffer  is  waiting  to  be  processed  by  th*» 
user's  program  and  the  terminal  user  attempts  to 
terminate  a  new  input  line. 

(2)  An  attempt  is  made  to  move  the  cursor  back  Dast  the 
start  of  the  current  line.   For  example*  attempting  to 
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delete  the  previous  line  or  character  after  the  line 
has  been  entered  by  a  termination  key  will  result  in  a 
beep . 

The  terminal  click  alert  is  associated  with  the 
display  scrolling  feature.  Since  the  display  buffer  also 
acts  as  an  inout  buffer*  scrollino  the  displav  when  the  51? 
byte  display  buffer  is  full  could  destroy  input  data  which 
has  not  yet  been  orocessed.  For  examolp,  the  user  could  be 
entering  a  512  character  strina.  Uoon  termination  of  that 
input  line*  MTS  will  lock  out  scrollino  until  the  user's 
proaram  has  processed  the  first  64  characters.  This  ensures 
that  the  input  data  is  not  destroyed  by  the  scrolling 
operation.  This  scrollinq  lockout  is  indicated  to  the  user 
by  a  terminal  click  alert. 

2.   Terminal  Key  Functions 

The  terminal  keys  fall  into  five  basic  functional 
groups:  keys  for  entry  of  normal  character  strinqs;  keys 
which  affect  the  interpretation  of  the  inout  kev  character; 
input  line  termination  keys?  line  editing  and  cursor  control 
keys?  and  number  pad  keys.  These  keys  and  their  functions 
are  described  in  the  followina  subsecions.  Within  the 
function  descriptions*  "current  position"  refers  to  the 
current  cursor  position  on  the  screen.  Any  reference  to  tne 
display  of  a  character  in  the  current  position,  also  implies 
that  the  current  position  is  incremented  by  one. 
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a.   Character  S  t  r  i  n  a  Keys 


KEY/SWITCH 


FUNCTION 


0-9 


Displays  the  input  numeric 
character  at  the  current 
position  on  the  screen. 


Spec  i  a  1 
Charac  t  ers 


Displays  the  in nut  special 
character  at"  the  current   cursor 
position  on  the  screen. 


A-Z 


Displays  the  input  alphabetic 
characters  at  the  current 
position  on  the  screen. 
Alphabetic  c^sr act ers  are 
disolayea  in  upoer  or  lower  esse 
depending  on  the  key  mode  (see 
SHIFT  and  FS  C  under  Entry  Mode 
Keys)  . 


Tab/Skip 


Displays  a  (horizonal)  tab  sym- 
bol at  the  current  position  on 
the  sc  reen . 


b.   Entry  Mode  Keys 


KEY/SWITCH 


FUNCTION 


FUNCTION 

SELECT(FS) 


Defines  the  interoretation  of 
keys  for   special   functions   as 
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I/O  CONTROL 
(I/O  CTL) 


SHIFT 


FS   C 


defined  in  this  section. 

Defines  the  i nt e rore t at i on  of 
keys  for  special  functions  as 
defined  in  this  section.  Also 
used  in  conjunction  with  the 
alphabetic  keys  to  generate 
aDprooriate  ASCTI  control  codes. 

Defines  the  interpretation  of 
keys  used  for  two  (£) 
characters.  Also  used  to 
capitalize  alspabetic  characters 
when  the  kev  entrv  mode  is  lower 
case  ( see  below). 

Sets  or  clears  the  alphabetic 
key  entry  mode  to  upper  or  lower 
case.  Functions  as  a  shift  kev 
1  oc  k  . 


c.   Line  Termination  Keys 


KEY/SWITCH 


FUNCTION 


NEW  lin^;  enter; 

I/O  CTL  M; 

shift  cr; 


Terminates  the  current  line  and 
establishes  the  just  completed 
input  line  as   an   input   buffer 
available   for  orocessing  by  the 
user's  program.   The   cursor   is 


1  n« 


ERROR  RESET 
(MTS  CMD) 


displayed   at   the    left    most 
position  of  the  next  line. 

Specifies  that  the  input  line 
which  it   terminates   is   to   be 
processed   by   ^TS   as   a  system 
command . 


d.   Line  Editing  and  Cursor  Control  Keys 


KEY/SWITCH 


FUNCTION 


BACK  SPACE 
(Char  Oelete) 

FS  S  or  I/OCTL  S 
(Clear  Sc  reen ) 


NEXT  F M A T  Deletes  all  characters  from  the 

(Line  Oelete)        current   position   back   to   the 

start  of  the  current  line. 

Deletes  the  previously  entered 
character. 

Clears  the  display  buffer  (not 
the  status  line)  and  leaves   the 
current   position   at   the  upper 
left   position   of   the   display 
buffer. 

<•-•  (Cursor  Left)   Moves  the  current   position   one 

to  the  left.  Does  not  delete 
previous  entry*  but  allows 
reen t  ry  . 

--->(Cursor  Right)   Moves  the  current   position   one 
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to  the  right.  Hoes  not  delete 
previous  entry/  but  allows 
reen t  ry. 

e.   Number  Pad    Keys 

The  number  pad  keys  consist  of  10  numeric  digits 
and  8  ASCIT  control  characters  located  on  the  rioht  side  of 
the  keyboard.  The  diaifs  function  in  the  same  manner  as  the 
other  numeric  digits  on  the  keyboard.  The  ASCII  control 
characters  are  displayed  when  the  SHIFT  key  is  depressed  in 
conjunction  with  the  aoorooriate  key.  The  only  control 
character  w^ich  affects  the  disolay  is  SHIFT  LP  (see  Line 
Termination  Keys). 

3.   MTS  System  Commands 

Svstem  commands  are    a  set  of  commands  whicn  rrovide 

the   user   with   a   means  of  communicatino  with  M T S  from  the 

terminal.   These  commands  allow  the  user  to   login  to   M T S ; 
guit   MTS/   attach   virtual  f loopy  disks;  protect/  restrict/ 

and  unprotect  virtual  floppy  disks;  and  soeci  fy  the  virtual 
memory  size  to  be  used. 

a.   General  Characteristics 

A  MTS  command  seauence  may  be  entered  anvtime 
after  the  initialization  or  reinitialization  of  MTS,  The 
user  enters  the  desired  command  sequence/  followed  by  the 
ERROR  RESET  key.  This  sianals  the  ooeratina  system  that 
there  is  an  MTS  command  to  be  orocessed.  Any  errors 
detected   in   the   command   seauence  will  result  in  an  error 


alert  messaae  displayed  in  the  MTS  message  field  on  the 
status  line.  Section  E  describes  the  MTS  status  line 
disolay  ana  provides  a  summary  of  the  error  messaaes. 

b .   Synt  ax  Pules 

The  followinq  rules  should  be  used  to   interpret 

the  syntax  for  each  system  command  qiven  in  sect-ion  D.3.e. 

CI)  The  command  may  be  entered  in   upoer   or   lower   case. 

MTS    converts    the    commands    to   uoper   case   for 

process  i  nq  . 

(2)  Each  entry  in  the  command  sequence  must   he   senarated 

by  one  or  more  soaces. 
( 3  )  The  entire  command  name  may  be  used  to  scecify  the 
command.  However  only  thf»  first  letter  of  the  command 
is  required*  as  indicated  bv  the  underscore  in  tne 
syntax.  MTS  validates  onlv  the  first  letter  of  the 
command  name. 

(4)  Parameters  are  shown  in  lower  case  and  enclosed  by 
inequality  signs  (<  >).  Each  parameter  name  is  a 
variable  which  must  be  replaced  bv  the  appropriate 
character  strinq  or  decimal  number  entered  by  the 
user . 

(5)  Parameters  may  be  required  or  optional*  rieoendino  on 
the  command.  Optional  parameters  are  specified  by 
enclosing  the  parameter  in  brackets  (t  1).  Tf  a 
parameter  is  desiqnated  as  optional*  it  may  be  omitted 
from  the  command  seauence  (see  section  D.3.d). 

(6)  The  designation  I  <  d  i  s  k  nr>   [ / < k e y > 1  J   indicates   that 
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the  entire  parameter  seauence  is  optional f  and  that 
<disk  nr>  may  aoDear  without  /<key>.  The  converse* 
however/  is  not  true. 

(7)  If  parameters  are  entered  in  a  command  sequence  thev 
must  be  in  the  order  specified  in  the  syntax.  For 
example*  <disk  nr>  may  not  be  entered  before  <drivp 
1  t  r>. 

(fi)  The  notation  (error  reset)  at  the  end  of  each  command 
strinq  is  a  reminder  to  the  user  that  each  MTS  command 
sequence  must  be  terminated  by  the  ERROR  PE.SET  key. 

c.   Parameter  Definitions 

The   system   commands    have    four    types    o * 
paramet  e  rs  : 

(1)  <drive  ltr>  -  must  be  one  of  the  alphabetic  characters 
A  throuqh  H.  It  specifies  one  of  the  eiaht  virtual 
disk  drives  availaole  to  a  terminal  user. 

( 2 )  <disk  nr>  -  must  be  a  decimal  number  in  the  range 
0-31.  It  specifies  one  of  up  to  ^2  virtual  floooy 
disk  files  on  the  Sycor  mini-disk. 

(3)  /<key>  -  a  strinq  of  not  more  than  four  characters* 
always  preceded  bv  the  special  character  '/'  which 
designates  the  strinq  as  a  key  oarameter.  All  vaMd 
ASCII  characters  are  acceptable  includinq  blank,  slash 
(/)*  and  other  special  characters. 

(4)  <memory  size>  -  must  be  a  decimal  value  in  the  range  0 
to  4ft t  which  specifies  the  user's  swao  image  size  in 
kilobytes.   The  default  value  for  a  user  swap  imaae  is 
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16K. 

d .   Default  Parameter  Values 

Certain  system  commands  allow  the  user  to  omit 
the  <drive  ltr>  and/or  <  d  i  s  k  nr>  oarafeters.  In  these 
cases;  ^  T  S  determines  the  aDprooriate  drive  letter  and  disk 
number  by  scanninq  its  allocation  tables  for  the  firs'- 
available  virtual  drive  or  virtual  disk,  as  aDDrooriate.  If 
one  is  found,  it  is  allocated  to  the  request ina  user. 
Otherwise  the  aoorooriate  error  messaoe  is  displayed. 

The  <key>  parameter  is  optional  only  if  t^e  disk 
requested  has  no  protection  attributes  specified.  Thus  there 
is  no  default  <kev>  value.  As  previously  mentioned/  the 
default  <memory  size>  parameter  is  1t>K. 


e.   Commana  Descriptions 

The  followinq  oaqes  describe  in  detail 
the  system  commands: 
(1)   ATTACH 
(?)   LOGIN 
(3)   PROTECT 
iU)       QUIT 

(5)  RESTRICT 

(6)  SIZE 

(7)  UNPROTECT 


eac  h   of 
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SYSTEM  COMMAND 


ATTACH 


Func  t  i  on  : 


To  attach  a  virtual  f 1 odpv  disk  to  a  virtual  disk 
for  use  by  a  user  at  a  specific  terminal. 


drive 


Synt  ax  : 

ATTACH  I<drive  ltr>l   [<disk  nr>  [/<key>3  ]  (error  reseM 

Desc  ri  Dt  i  on : 

This  system  command  simulates  the  physical  ODeration  of 
loading  virtual  disk  <disk  nr>  into  virtual  arive  <drive 
ltr>.  All  Darameters  are  ODtional/  section  D.3»d 
describes  the  default  values  when  optional  para meters 
are    om  i  1 1  ed. 


Error  Messaaes: 

INVALID  OD 
DRIVE  NOT  AVAIL 


DISK  NR  ERROR 
DISK  IN  USE 

DRIVE  LTR  ERROR 
DISK  NOT  AVAR 


KEY  ERROR 


Syntax  error  in  command  sequence. 

Drive  letter  has  not  been 

snecified  and  there  is  no  drive 

presently  available  for  assignment. 

Disk  number  entered  is  oreater 

than  31 . 

Disk  number  specified  is  presently 

allocated  with  read/write  access  to 

anot  her  user. 

Drive  letter  entered  is  not  one  of  the 

letters  A  t  h  rouqh  H. 

Either  disk  number  has  not  been 

specified  and  there  is  no  disk 

presently  available  for  assignment;  or 

the  specified  disk  is  not 

available  for  assignment. 

The  specified  disk  reauires  a  key 

and  either  a  key  has  not  been  entered 

or  the  entered  key  did  not  match. 


Exampl es  : 


ATTACH  A  3  /USR1 

A  C 

attach  S  /vd#l 
a   1 


SYSTEM  COMMAND 


LOGIN 


Func t  i  on : 


Links  the  terminal  user  to  MTS  and  Drovides  the  initial 
load  of  the  user's  program  or  operating  system  (default 
system  i  s  CP/M) . 


Synt  ax  : 

LOGIN  [<disk  nr>  f/<key>ll  (error  reset) 


Desc  r  i  pt  i  on  : 

This  system  command  notifies  M T S  that  the  reauestino 
terminal  is  now  active*  and  simulates  t^e  physical 
cold-start  hootstrao  operation  of  the  user's  system. 
The  bootstrao  load  always  takes  place  from  virtual  Hrive 
A.  The  virtual  disk  (and  associated  key*  if  anyl 
attached  to  this  drive  may  be  specified  as  a  parameter. 
The  default  is  disk  np  0,  which  is  a  read  onlv  dis<  and 
always  contains  the  C  P  /  M  ooeratina  system. 


Error  Messaaes: 

DISK  NR  ERROR 
DISK  IN  USE 

DISK  NOT  AVAIL 
HARDWARE  ERROR 


INVALID  CMD 


Disk  number  entered  is  ar^ater 

than  31  . 

Disk  number  specified  is  oresentlv 

allocated  with  read/write  access  to 

anot  her  user. 

The  soecified  disk  is  not  available 

for  ass  i  qnment . 

Abnormal  comoleticn  status  was 

returned  by  the  mini-disk  controller 

following  a  write  ooeration.   This 

may  indicate  that  the  last  virtual 

disk  written  to  was  not  closed 

prooerly  and  data  has  been  lost. 

Syntax  error  in  command  seauence. 


Examp 1 es : 


LOGIN  3  /Dl 

L   15 

login  25  /d25 

1 
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SYSTEM  COMMAND 


PROTFCT 


Function: 


Adds   the   read/write   protection 
specified  virtual  disk. 


attribute 


to 


t-  he 


Synt  ax  : 

PROTECT  <disk  nr>  /<key>  (error  reset) 

Desc  ri  pt  i  on  : 

This  system  command  provides  th<>  user  with  the  means  for 
on-line  assianment  of  a  protection  <key>  to  <disk  nr>. 
This  protection  may  also  be  added  off-line  using  the 
Sycor  440  system  software  (see  section  C.5). 


Error  Messaaes: 

DISK  NR  ERROR 

HARDWARE  ERROR 

INVALID  CMD 
KEY  ERROR 


-  Disk  number  entered  is  greater 
than  31. 

-  Abnormal  completion  status  was 
returned  by  the  mini-disk  controller 
followinq  a  read    or    write  operation. 

-  Syntax  error  in  command  sequence. 

-  The  specified  disk  is  already 
protected.   To  chanae  protection  kevs 
use  UN PROTECT  with  current  key  and 
then  PROTECT  with  new  key. 


Exampl es  : 


PROTECT  1  /VFD5 
prot ec  t  10  /key  1 
p  2    /uU?Q 


1  1  A, 


SYSTEM  COMMAND 


QUIT 


Func  t  i  on  : 

Terminates  the  terminal  user's  link  to  ^JS 

Syntax  : 

QUIT  (error  reset  ) 


Description: 

This  system  command  notifies   MTS 
terminal  is  no  longer  active. 


that   the   request  inn 


Error  Messages : 

HARDWARE  ERROR 


INVALID  CMD 


-  Abnormal  compleMnn  status  was 
returned  by  the  mini-disk  controller 
followina  a  write  operation.   This  mav 
indicate  that  the  last  virtual  disk 
written  to  was  not  clospd  orooerlv  and 
data  has  been  lost. 

-  Syntax  error  in  command  seauence. 


Exampl es  : 

QUIT 
qui  t 

Q 
q 
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SYSTEM  COMMAND 


RFSTRTCT 


Function: 


Adds  the  read  restriction   attribute 
virtual  disk. 


to   the   spec  i  f  i  ed 


Svnt  ax : 

RESTRICT  <disk  nr>  /<kev>  (error  reset) 

Desc  r i  pt  i  on : 

This  system  command  provides  the  user  with  the  means  for 
on-line  assignment  of  a  "read  onl v"  restriction  to  <oisk 
nr>.  This  allows  the  user  to  specify  a  previously 
protected  virtual  f 1 ooov  disk  as  available  to  other 
users  for  read  only  access. 


Error  Messaoes: 

DISK  (MR  ERROR 

INVALID  CMD 
KEY  ERROR 


-  Disk  number  entered  is  created 
than  31  . 

-  Syntax  error  in  command  seauence. 

-  The  specified  aisk  reauires  a  kpy 

and  either  a  key  has  not  been  entered 
or  the  entered  key  did  not  match. 


Exampl es : 


RESTRICT  3  /ID  1 
R  U       /    ID4 
rest  r  i  c  t  13  /usr3 
r  16  /l 
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SYSTEM  COMMAND 


STZF 


F  u  n  c  t ion: 


Specifies   the   memory   size   to   be   allocated   to   the 
terminal  user . 


Syntax  : 

SIZE  <memorv  size>  (error  reset) 


Desc  r  i  pt  i  on  : 

This  system  command  sets  the  size   of 
image.    The  range  of    values  is  0-48K. 
after  loqin  is  tbK.   is  entered. 


the   user's   swan 
The  default  vaue 


Error  Messaaes: 
INVALID  CMD 
OUT  OF  BOUNDS 


-  Syntax  error  in  command  sequence. 

-  Either  the  size  oarameter  entered 
does  not  fall  in  the  ranqe  of 
0-48;  or  the  Sycor  4  4  0  swap  file 
is  not  larqe  enouah  to  hold  this 
size  swao  imaae  (see  section  C.3) 


Exampl es : 


STZE  pa 
S  1? 

size    48 
s     0 
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SYSTEM  COMMAND 


UNPROTECT 


Func t i  on  : 


To  remove  a  previously  entered  protection  key 
specified  virtual  flopDy  disk. 


from   the 


Svnt  ax  : 

UNPROTECT  <disk  nr>  /<kev>  Terror  reset) 

Description: 

This  system  command  provides  the  user  with  the  means  for 
on-line  removal  of  all  protection  attributes  from  <  d  i  s  k 
nr>.  This  protection  may  also  be  deleted  offline  usino 
the  Sycor  4^0  system  software  (see  section  C  .  ^  )  . 


Error  Messaaes: 

DISK  MR  EPRDR 

HARDWARE  ERROR 

INVALID  CMD 
KEY  ERROR 


-  Disk  number  entered  is  areater 
t  ban  3 1 . 

-  Abnormal  completion  status  was 
returned  by  the  mini-disk  controller 
followinq  a  read  or  write  operation. 

-  Syntax  error  in  command  sequence. 

-  A  protection  key  is  required  and 
either  no  key  was  entered*  or 
the  entered  key  did  not  match. 


Exampl es : 


UNPROTECT  18  /NR  9 
U   12   /096a 
unprotect  7  /Ovfd 
u  9       /0?&% 
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E.   MTS  STATUS  LINE  MESSAGES 

The  MTS  ooerating  system  utilizes  the  first  line  of  each 

terminal   for  system  status  and  error  messaqe  aisnlays.  The 

status  line  is  64  characters  in  length  and  is   divided  into 
three  disolay  areas  as  shown  below. 

STATUS  LIME 


t>9    40 


47  48 


b^ 


V  F  D 


M  S 


m  S  R 


where 

VFD 

MS 

MSG 


Virtual  Floooy  Disk  Status  Display 
Memorv  Size  Disolay 
Error  Messaae  Display 


1.   Virtual  Flonpv  Disk  Status  Display 

This  display  contains  information  on  the  virtual 
drive  and  disk  assignments  currently  in  effect.  For  each 
attached  virtual  floppy  disk  the  followino.  will  be 
di  spl ayed: 

(1)  drive  letter 

(2)  disk  number 

(3)  restriction  indicator  (r  or  blank) 

For  example*  if  the  user  has  attached  disk  number  3  to  drive 
A  and  disk  number  25  (which  is  restricted")  to  drive  C,  the 
status  display  would  apoear  as  follows: 
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;a  =  03 


10 


C  =  25r 


39 


2.   Memory  Size  Disolav 

The  center  of  the  status  line  display  shows  the 
current  memory  size  for  that  user  and  the  "MTS"  header.  For 
example*  if  the  system  default  memory  size  were  being  used, 
the  display  would  anpear  as  follows: 

40      47 
16K  *"TS 


3.   Error  Messaae  Display 

All  MTS  system  commands  are  validated  ana  an  error 
alert  qenerated  if  any  syntax  errors  are  found.  The  last  16 
positions  of  the  status  line  are  reserved  for  these 
messaqes.  A  valid  system  command  will  clear  the  error 
messaae  display  of  any  previous  error  alert.  The  followinq 
is  a  summary  of  system  error  messaqes. 


MESSAGE 


ME AM  IMG 


(Blank  Display)    Initial  condition;  also  the  status  message 

area   is   cleared  followinq  the  processino 
of  a  valid  system  command. 

DISK  IN  USE  Disk  number  soeci*ied  is  presently  allo- 
cated with  read/write  access  to  another 
user . 
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DISK  NOT  AVAIL 


DISK  NR  ERROR 


Either  the  disk  number  has  not  been  speci- 
fied and  there  is  no  disk  presently 
available  for  assignment;  or  specified 
disk  number  is  not  available  for 
ass  i  qnment  . 

Disk  number  entered  is  greater  than  31. 


DRIVE  LTR  ERROR    Drive  number  entered  is   not   one   of   the 

letters  A  throuah  H . 

DRIVE  NOT  AVAIL    Drive  letter  has  not   been   specified   and 

there   is  no  Hrive  presently  available  for 
ass  i  qnment . 


HARDWARE  ERROR 


INVALID  CMD 


KEY  ERROR 


QUI  OF  BOUNDS 


Abnormal  completion  status  was  returned  bv 
the  mini-disk  controller  following  a  read 
or  write  operation.  May  indicate  hardware 
errors  on  peripheral  devices  as  additional 
devices  are     included  in  the  system. 

Syntax  error  has  been  detected  in  the 
command  seauence. 

The  specified  disk  reauires  a  key  and 
either  a  key  has  not  been  entered  or  the 
entered  key  did  not  match. 

A  numeric  parameter  has  been  specified 
which  exceeds  the  valid  bounds  for  that 
paramet  er . 
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TASK  DELETED 


When  RECOVERY  is  specified  durinq  system 
initial ization,  this  messaqe  is  displayed 
at  the  terminal  which  was  execution  when 
the  system  failure  occurred.  It  indicates 
that  this  terminal  user  must  reestablish 
the  environment. 
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F.   MTS/USER  PROGRAM  INTERFACF 

1.   Program  Interface  Design 

MTS  was  designed  to  provide  a  timeshared/  virtual 
8080  m i c roorocessor  environment  for  microcomputer  systems 
development.  The  term  virtual  is  appropriate  here  because 
the  user  actually  interfaces  with  MTS  for  many  services 
normally  provided  by  hardware  in  a  dedicated  OP  I.I 
environment.  A  software  interface  between  user  proorams  and 
the  Sycor  440  hardware  is  necessary  in  order  to  allocate  the 
hardware  resources  eauitablv  and  efficiently/  while  at  the 
same  time  satisfyino  the  service  reauirements  of  several 
competing  user  programs. 

The  MTS/user  crogram  interface  consists  of  a  set  of 
service  routines  which  may  be  called  by  a  user  program 
throuah  a  sinale  entry  point  to  perform  terminal  1/0/  access 
virtual  floppy  disks/  or  modify  the  user's  virtual 
environment.  The  design  was  heavily  influenced  bv  the  CP/M 
operating  system  which  us«*s  a  similar  scheme  for  I/O. 

The  set  of  service  routines  may  be  looically  divided 
into  two  types  of  calls  on  MTS.  The  first  tvpe»  svstem 
calls/  perform  the  same  functions  for  a  user  program  as 
system  commands  provide  for  the  user  at  a  terminal  (P. 3). 
The  functions  deal  with  modifyina  the  user's  current  virtual 
environment  by  chanoing  memory  size/  attaching  various 
virtual  disks  to  virtual  drives/  or  even  loogina  on  ana  off 
the  system.  Service  calls  are  the  second  type  of  call 
provided  by  the  MTS  software  interface.   Service   calls  are 
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used  to  perform  terminal  I/O  and  access  virtal  floooy  disks. 
A  call  to  MTS  takes  the  form 

<va1ue>  =  MTSC<fid>f<parm>) 
The  first  arqument#  <fid>*  is  a  number  from  0  to  17  which 
identifies  the  function  reauested.  The  <oarm>  argument  rnav 
be  a  parameter  valuer  if  onlv  a  sinqle  parameter  is 
required^  or  the  address  of  a  parameter  list  if  more  than 
one  parameter  is  required.  In  each  case  MTS  returns  <  v  a  1  u  e  > 
uoon  completion  of  the  reau«steH  operation.  This  returned 
value  may  be  an  ASCII  character  code;  an  error  code*  or  in 
several  cases  have  no  siqnificance.  Roth  svstem  calls  and 
service  calls  are  formed  as  described  above.  The  svnta*  and 
function  of  each  call  are  described  in  the  follow  ina 
sec  t  i  ons  . 
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2 .   System  Calls 

All  system  commands  available  to  a  user  at  a 
terminal  are  also  available  to  a  user  prooram  throuoh  system 
calls.  An  additional  call  is  provided  which  will  display  an 
appropriate  terminal  alert  at  the  user's  terminal  if  entered 
with  an  error  code.  Table  1  summarizes  the  required 
arguments  and  return  values  of  each  system  call. 


FID 

0 
1 
2 
3 
a 

5 
6 

7 


TABLE  1 
SYSTEM  CALL  SUMMARY 
NAME  PARM 


ATTACH 

DISPLAY  MSG 

LOGTN 

PROTECT 

QUIT 

RESTRICT 

SIZE 

UNPPOTECT 


list 

error  code 

list 

1  i  st 

none 

1  i  st 

s  i  ?e 

1  i  st 


VALUE 

error  code 
none 

error  code 

error  code 
none 

error  code 

error  code 

error  code 


a  .   Argument  s 

Each  system  call  is  identified  by  a  number  which 
MTS  associates  with  a  particular  service  routine.  In 
addition  to  this  function  identifier*  MTS  may  require  one  or 
several  additional  parameters  to  perform  the  reouested 
service.  When  more  than  one  parameter  is  reauired;  MTS  must 
be  passed  the  address  of  a  bvte  vector  containina  these 
parameters.   Each  system   call   reauires   that   this   vector 
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conform  to  some  fixed  format.  Tn  qeneral  each  byte  of  the 
vector  will  contain  some  numeric  value  or  an  &SCII  character 
code*  but  situations  may  arise  wh?n  an  optional  parameter  is 
not  specified.  Tn  such  cases  the  corresoonaina  byte  in  the 
parameter  vector  must  be  filled  with  the  value  FFH. 

b.   System  Call  Descriptions 

The  following   oaaes   describe   in   detail   each 
system  call. 
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SYSTEM  CALL 


ATTACH 


Func t i  on : 


To  attach  a  virtual  floppy  disk  to  a  virtual  disk   drive 
for  use  by  a  user  at  a  specific  terminal. 


Argument  s : 
FID  =  0 


PARM  =  address  of  parameter  vector 

byte  0:  drive  number  where  A  =  0,  B=l,  etc. 

byte  1:  disk  numbpr  -  0  t o  3 1 

bytes  2-5:  protection  key  -  0  to  4  ASCIT  characters 


Desc  r  i  ot  ion: 

This  call  simulates  the  physical  operation  of  loaaino 
virtual  disk  <disk  nr>  into  virtual  drive  <drive  nr>. 
All  parameters  are  optional.  If  disk  and/or  drive  nr  is 
not  specified  MTS  searches  the  disk  or  drive  mao  table 
respectively  for  the  first  available  entry.  A 
protection  key  is  onlv  reauired  if  the  virtual  d i s k  to 
be  attached  has  reen  assioned  read/write  protection. 
The  call  returns  an  error  code  uoon  completion. 


Error  Codes : 

1  -  Operation  successful 

2  -  Either  disk  number  has  not  been  specified  and  there 

is   no   disk  presently  available  for  assignment;  or 
the  specified  disk  is  not  available  for  assianment. 

3  -  Disk  number  specified  is  presently   allocated   with 

read/write  access  to  another  user. 

4  -  Disk  number  specified  is  qreater  than  ^1. 

5  -  The  specified  disk  requires  a  key  and  either  a   key 

has   not   been   entered   or  the  entered  kev  did  not 
match  . 

6  -  Drive  number  specified  is  areater  than  7. 

10  -  Drive  number  has  not  been  specified  and  there  is  no 
drive  presently  available  for  assianment. 
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SYSTEM  CALL 


DISPLAY  MSG 


Function: 


To  display  a  terminal  alert  in  the  status 
of  the  user's  terminal. 


messagp   area 


Argument  s : 
FID  =  1 
p ar^  r  error  code 

Description: 

This  call  takes  an  error  code  as  input  and  displays  the 
corresponding  predefined  terminal  alert  messaqe  on  th» 
user's  terminal.  The  DTSPLAY  MSG  system  call  provides 
the  only  way  for  a  user  to  display  messages  on  t-he 
terminal  status  line.  Mo  value  is  returned  bv  tMs 
system  call. 


Act  i  on 

0 
1 

2 
3 

a 
5 

6 
7 
8 
9 
10 


blank 

INVALID  CMD 
DISK  NOT  AVAIL 
DISK  IN  USE 
DISK  NR  ERROR 
KEY  ERROR 
DRIVE  LTR  ERROR 
OUT  OF  BOUNDS 
HARDWARE  ERROR 
TASK  DELETED 
DRIVE  NOT  &VAIL 
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SYSTEM  CALL 


LOGIN 


Func  t  i  on  : 


Reinitializes  the  user's  ^  T  S  environment  and  reboots  the 
user's  system  from  drive  A. 


A  rgument  s  : 
FID  =  2 


PARM  s  address  of  parameter  vector 
byte  0:  disk  number  -  0  to  31 
bytes  1-4:  protection  kev  -  0  to 


4  ASCII  charac  ters 


Desc  ri  pt  i  on  : 

This  system  call  creates  a  reinitialized  M T S  environment 


for    the  user  program. 


'pmory  s i z e  is  set  to  \ bK    and  the 


specified  disk,  if  any,  will  be  attached  to    drive  A .   I  * 


no   disk   number 
the  CP/M   system 
memo rv   size  will 
use  r  '  S  terminal, 
drive  A  . 


is  soecified,  disk  number  0  contain  i no 
is  attached.  Drive  assianment  and 
b*»  displayed  on  the  status  line  o*  the 
The  user  system  is  then  rebooted   from 


Error  Codes : 


8  - 


Operation  successful 

The  specified  disk  is  not  available  for  assignment. 

Disk  number  specified  is  currently   allocated   with 

read/write  access  to  another  user. 

Disk  number  specified  is  qreater  than  31. 

The  specified  disk  reauires  a  kev  and  either  a   key 

has   not   been   entered   or  the  entered  kev  did  not 

match. 

Abnormal  completion   status   was   returned   by   the 

mini-disk   controller   following  a  write  operation. 

This   may   indicate   that   the   last   virtual   disk 

written   to   was   not   closed  Droperly  and  data  has 

been  lost. 
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SYSTEM  CALL 


QUIT 


Func  t  i  on  : 

Logs  the  user  oM  MTS. 

Argument  s  t 
FID  =  a 
PARM  r  none  required 

Description: 

This  system  call  notifies  MTS  that  the  rpauest  ina  user 
p  r  o  a  r  a  m  is  no  lonaer  active.  Control  will  not  b  ^ 
returner!  to  the  user  oroqram.  The  user  must  Ion  in 
through  the  terminal  to  regain  system  facilities. 

Error  Codes : 

0  -  Ooeration  successful, 

8  -  Abnormal  completion  status  was  returned  by  top 
mini-disk  controller  followinq  a  write  ooeration. 
This  may  indicate  that  the  last  virtual  disk 
written  to  was  not  closed  properly  and  data  has 
been  lost.  Tf  this  error  code  is  returned/  the 
terminal  alert  HARDWARE  ERROR  is  automatically 
displayed  in  the  status  message  ?irea  of  the  user's 
terminal . 
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SYSTEM  CALL 


SIZE 


Function: 

Set  the  amount  of  memory  available  to  the  user. 

Argument  s : 
FID  =  6 
pARM  =  memory  size  in  kilobytes 

Desc  rot  i  on : 

This  system  call  adjusts  the  size  of  the  user's  swao 
image  to  the  specified  value.  The  value  must  fall  in 
the  ranae  0  to  4  8 ,  and  also  must  not  be  qreater  than  the 
size  of  the  swap  file  associate  with  the  user's 
terminal . 

Error  Codes : 

0  -  Operation  successful. 

7  -  Either  specified  size  exceeds  4 8 K ,  or  a  value  less 
than  4  8  K  exceeds  the  size  of  the  available  swap 
f  i  le. 
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3.   Service  Calls 

The  MTS  environment  currently  orovides  a  virtual  CRT 
terminal   as   the  primary  I/O  device  and  virtual  floppy  aisk 

drives  for  auxiliary   storaoe.    Access   to   both   of   these 

/ 

virtual  devices  is  throuah  MTS  service  calls.  A  summary  of 
the  service  calls  showing  parameters  and  returned  values  is 
given  in  Table  2 . 

TABLE  2 

SERVICE  CALL  SUMMARY 


none 


FID  NAME              PARM 

8  TERMINAL  STATUS 

9  READ  TERMINAL 

10  WRITE  TERMINAL 

11  dRITF  PRINTER 

12  SELECT  DRIVE 

13  SET  DMA 
ia  SET  TRACK 

15  SET  SECTOR 

16  READ  FLOPPY  none 

17  WRITE  FLOPPY  none 


VALUE 

t  rue/fal se 
none  character 

character     none 
character     none 
drive  n  r      error  code 
dma  adaress  error    code 
track  n  r      none 
sector  or     error  code 

none 

none 


a.   Virtual  Terminals 

The  MTS  virtual  terminal  simulates  the  operation 
of  a  serial  half-duplex  console  device.  Single  ASCII 
characters  may  be  passed  from  the  terminal  keyboard  to  a 
user   prooram,   or   from   a  user  orogram  to  the  terminal  for 
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display.  A  service  call  to  MTS  is  required  to  pass  each 
character.  MTS  also  Drovides  a  terminal  status  service  call 
which  allows  a  user  oroqram  to  test  the  status  of  a 
t ermi  na 1  . 

The  user  should  keep  in  mind  that  characters  are 
actually  being  passed  between  his  oroqram  and  the  terminal 
display  buffer  (0.1. b).  This  means  that  input  need  not  be 
echoed  by  the  user's  oroqram  since  it  already  aopears  on  fh? 
display.  Simple  line  editinq  is  also  provided  by  MTS  on  the 
input  data  prior  to  m  a  k  i  n  o  that  data  available  *  or 
processing  by  the  user's  prooram. 

The  user  can  directlv  contribute  to  improved 
system  response  by  proper  use  of  the  terminal  service  caPs. 
It  is  common  oractice  when  writinq  conversational  proorams 
to  implement  a  Hoet  character"  routine  to  hanqle  input  from 
the  terminal.  Normally  this  routine  does  little  more  than 
repeatedly  test  the  terminal  status  until  it  finds  input 
waitinq.  In  the  MTS  environment  a  more  efficient  method  of 
accomplishinq  the  same  qoal  is  to  immediately  read  f  r  o  ^  the 
terminal  without  testinq  for  status.  If  input  is  waitinq, 
the  first  character  will  be  passed  immediately.  More 
importantly,  if  there  is  no  input  waitinq,  MTS  will  block 
the  user's  program  until  a  character  is  entered  at  the 
keyboard.  The  blocked  oroqram  may  be  swaoped  out  and  toe 
CPU  allocated  to  another  user.  This  method  of  implementing 
conversational  programs  takes  advantage  of  unproductive 
waiting  time  in  one  user  prooram  to  service  additional 
users . 
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b.   Virtual  FIoppv  Disk  Drives 

The  MTS  virtual  floppy  disk  drive  provides 
auxiliary  storaae  for  user  proqrairs  on  virtual  floppy  aisks. 
These  hard-sectored  disks  have  1?8  bytes  per  sector^  2h 
sectors  per  track,  and  a  maximum  number  of  tracks  determined 
by  the  size  of  the  file  containina  the  disk  image  (C.S). 
Each  user  has  eight  drives  available  for  dedicated  use. 

Drive  A  is  activated  when  the  user  loos  in  and 
serves  as  the  user  system  load  device.  In  a  Drocess  whicH 
simulates  a  cold-star''  bootstrap  load  the  first  four  sectors 
on  track  0  are  read  into  the  user's  memory  space  at  location 
4  0  0  0  H  .  MTS  assumes  that  these  sectors  contain  executable 
code  which  will  load  the  remainder  of  the  user's  system. 
Unless  another  disk  is  specified  in  the  LOGIN  command 
strincw  a  read-only  disk  containing  the  C  P  /  M  operating 
system  will  be  attached  when  drive  A  is  activated. 

The  user  may  activate  any  or  all  of  the 
remaining  virtual  drives  by  attaching  a  virtual  disk.  This 
is  accomplished  from  the  terminal  by  enter  i  n  q  the  ATTACH 
system  command  or  directly  from  the  user's  oroqram  by  a  call 
to  MTS.  Althouoh  no  direct  method  for  detachina  a  virtual 
disk  is  provided  by  MTS,  the  same  effect  is  produced 
indirectly  by  overridina  the  current  drive  assianment  with  a 
second  ATTACH  command.  tohen  the  second  floppy  disk  is 
attached  MTS  closes  the  previously  attached  disk  and 
releases  it  for  use  elsewhere. 

Data  transfer  between  a  virtual  disk  and  a  user 
program   utilizes   a   128   byte  buffer  in  the  user's  proqram 
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space  called  a  DMA  buffer.  The  name  is  derived  from  t-ne 
nature  of  the  transfer  operation:  to  the  user  proaram  if 
appears  that  data  transfer  is  by  direct  memorv  access. 

Before  the  user  proaram  can  access  a  particular 
virtual  disk  sector  the  user  must  specify  a  complete  sector 
address  and  a  DMA  buffer.  A  complete  sector  address  consists 
of  drive*  track,  and  sector  numbers.  Note  that  MTS  will  not 
allow  a  virtual  drive  to  be  selected  until  a  disk  has  been 
attached.  A  DMA  buffer  is  defined  by  i  t-  s  base  address.  MTS 
provides  a  service  call  to  enter  each  of  these  four  valu°s. 
Once  a  value  has  been  entered  it  will  be  used  for  all 
subsequent  virtual  disk  accesses  until  redefined  by  a  second 
service  call. 

C .   A  rqumen  t  s 

Service  calls  have  the  same  form  as  other  calls 
to  MTS.  A  numerical  function  identifier  is  associated  with 
each  call  to  identify  the  service  desired.  The  second 
argument  is  a  single  parameter  in  most  cases,  although 
several  of  the  service  calls  reouire  no  second  araument. 

d.   Service  Call  Descriptions 

The  following  pages  describe  in  detail  each 
individual  service  call. 
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SERVICE  CALL 


TERMINAL  STATUS 


Function: 

Interrooate  the  status  of  the  user's  terminal. 

Argument  s : 
FID  =  8 
PARM  =  none  required 

Description: 

This  service  call  returns  a  logical  value  answerina  the 
question  "Ts  terminal  incut  waiting?"  TFRMTNAL  STATUS 
should  not  be  used  in  those  situations  where  no  further 
processina  can  he  accomplished  until  terminal  input  is 
available.  In  such  a  case  it  is  more  efficient  to  use 
the  READ  TERMINAL  service  call  to  allow  processing  of 
other  user  tasks  while  waitino. 

Val ue: 

00H  -  all  terminal  innuf  processed 
FFH  -  terminal  inout  waitina 
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SERVICE  CALL 


READ  TERMINAL 


Func t  i  on : 


Read   the 
terminal . 


next   available   character   from   the   user's 


Argument  s : 
FID  =  9 
PARM  =  none  reauired 

Description: 

This  service  call  passes  the  next  ava i la  b 1 e  A3CIT 
Character  from  the  user's  terminal  disDlav  buffer  to  the 
user  program.  The  maximum  si  z°  incut  line  is  SI? 
characters.  Each  input  line  is  terminated  by  a  csrrigqe 
return.  It  is  not  necessary  for  user  proorams  to  echo 
input  characters  since  thev  are  already  displayed  on  the 
user's  terminal  before  beco^inq  available  *■  o  the  user 
proaram.   Line  editina  functions  are    provided  by  M T S • 

Val ue: 

A  sinqle  ASCII  character  -  the  end  of  each  inout  line  is 
indicated  by  the  return  of  a  carriage  return  (ASCII  = 
ODH)  . 
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SERVICE  CALL 


WRITE  TFRMiMAL 


Funct ion: 

To  write  a  character  to  the  user's  terminal. 

Argument  s : 

FID  =  10 

PARW  =  a  single  ASCII  character 

Oesc  r  i  ot  i  on : 

This  service  call  passes  the  soecifiea  character  from 
the  user  program  to  the  terminal  display  buffer  for 
display.  Carriage  return  (  A  S  C  T  I  =  0  D  H )  returns  the 
cursor  to  first  position  of  the  current  line.  Line  Feed 
(ASCII  =  OAH)  moves  the  cursor  down  one  line.  tacK 
outDut  line  will  normal  I v  be  terminated  by  the  CR-LF 
comb  i  nat  i  on . 

Val ue: 

None  returned. 
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SERVICE  CALL 


SFLECT  DRIVE 


Function: 


Selects  the  virtual  floopv  disk   drive 
subsequent  flopoy  disk  accesses. 


to   be   used 


i  n 


Argument  s  : 

FID  =  12 

PARM  =  drive  number  where  A=l,  B=? ,     etc. 

Desc  r  i  pt  i  on  : 

This  service  call  selects  one  of  the  eight  virtual 
floppy  disk  drives  available  to  pach  user  nrogram  for 
use  in  subsequent  floooy  disk  accesses.  Before  a  drive 
can  be  selected*  a  virtual  disk  must  be  attached. 

Error  Codes : 

0  -  Operation  Successful. 

6  -  Drive  number  specified  is  greater  than  7.   Selected 
drive  is  changed. 

10  -  Drive  specified  is  not  in  use.  Indicates  that-  no 
virtual  disk  has  he?n  attached  to  the  specified 
drive.   Selected  drive  is  unchanoed. 
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SERVICE  CALL 


SET  DMA 


Func  t  ion: 


Sets  the  base  address  of  the  12*  byte  DMA 
used  in  subseauent  floppy  disk  accesses. 


buffer   to   be 


Argument  s : 
FID  =13 
PARM  =  base  address  of  DMA  buffer 


Desc  r  i  Pt  i  on : 


The  DMA  buffer  recuired  to  access  a  virtual  f 1 oppv  disk 
must  oe  a  continuous  block  of  128  bvtes  located  in  the 
user's  memory  SDace»  i.e.  with  base  address  areater 
than   4000H.    SoArifvSna   a  DMA  adHrps<;  orpafpr  than  or 


than   aOOOH.    Specifying   a 

equal  to  FFOOH  will  have  unpredictable  results*  but 
normally  be  expected  to  cause  a  svstem  crash 
subseauent  deletion  of  the  user's  task  upon  recovery. 


address  greater  than  or 

can 
crash   and 


Error  Codes : 

0  -  Operation  successful. 

7  -  Address  specified  is  less  than  the  base  of  user's 
memory  snace.  Current  DMA  address  remains 
unc  hanaed . 
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SERVICE  CALL 


SET  TRACK 


Function: 


Set  s   the   f 1 oooy 
subsequent  virtual 


disk   track 
f 1 oppv  disk 


numbe  r   to 
accesses . 


be   used   in 


A  rgumen t s : 

FID  =  14 

PflRM  =  track  number  -  0  to  256 

Desc  ri  Pt  i  on  : 

This  service  call  sets  the  track  numbpr  to  be  used  in 
subsequent  floopy  disk  accesses.  Values  mav  range  from 
0  to  256.  The  value  cannot  be  validated  until  it  i  ^ 
associated  with  a  virtual  floopy  disk  number;  thereforer 
no  validation  is  performed  until  a  read  or  write 
operation  is  requested. 

Val ue: 

None  returned. 
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SERVICE  CALL 


SFT  SECTOR 


Func t  i  on  : 


Sets  the   floDpy   disk   sector   number   to   be   used 
subsequent  virtual  floDpy  disk  accesses. 


1  n 


A  rgument  s  : 

FID  =  IS 

pARw  =  sector  number  -  1  to  26 

Desc  r  i  pt  i  on : 

This  service  call  sets  the  sector  number  to  be  used  '  in 
subsequent  virtual  f  Ioddv  disk  accesses.  Since  e  a  c  *"* 
floppy  disk  track  contains  26  sectors  numbered  from  1  to 
26#  this  value  cannot  be  less  than  I  nor  qreater  t^an 
56. 

Error  Codes  : 

0  -  Ooeration  successful. 

7  -  Sector  number  specified  is  less  than  1  or  oreater 
than  26.  Current  value  of  sector  number  regains 
unchanoed . 


laa 


SERVICE  CALL 


READ  FLOPPY 


Func t  i  on : 

Simulates  reading  a  128  bvte  sector  from  a  flopoy  disk 

Argument  s : 

FID  =  16 

PARM  =  none  rpqui  red 


Desc  r  i  ot  i  on : 
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Error  Codes: 

0  -  Operation  successful. 

7  -  Calculated  mini-disk  address  out  of  bounds.    Prob- 

able error  in  specified  track  number. 

8  -  Abnormal  completion   status   was   returned   by   the 

mini-disk   controller   following   a   read   or  write 
operat  i  on . 
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SERVICE    CALL 


foRITE    FLOPPY 


Funct i  on : 

Simulates  writing  a  128  byte  sector  to  a  floppy  disk 

Argument  s : 

FID  =  17 

PARM  =  none  required 


Description: 
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Error  Codes : 

0  -  Operation  successful. 

7  -  Calculated  mini-disk  address  out  of  bounds.    Prob- 

able error  in  specified  track  number. 

8  -  Abnormal  completion   status   was   returned   by   the 

mini-disk   controller   following   a   rpad   or  write 
operat  i  on . 
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4.   Calling  Procedure 

All  calls  to  ^TS>  whether  system  calls  or  service 
calls*  are  made  through  a  sinale  entry  Doint  at  location 
2000H.  Each  call  takes  two  arguments:  the  function 
identifier  in  register  C;  and  a  Darameter  value  or  address 
in  register  pair  DE.  In  those  cases  where  the  second 
argument  is  only  a  single  byte  the  contents  of  the  D 
register  are  ignored. 

EacH  call  to  VTS  returns  a  value  in  the  A  reoister. 
This  value  may  be  an  error  code*  an  ASCII  character  cod°/  or 
zero.  The  value  zero  is  returned  by  those  routines  whose 
value  has  no  significance  such  as  WRITE  TERMINAL  or  SET 
TRACK. 

Note  that  the  register  assignments  for*  arguments  and 
returned  values  conform  to  the  P  L  /  M  convention  for  passina 
parameters.  The  followina  examoles  illustrate  the  callino 
procedure  for  P0?0  Assembly  Lanquaae*  N*LR0,  and  PL/M  in  the 
MTS  environment.  Each  example  illustrates  the  seauence 
reguired  to  read  floopy  disk  sector  22,  track  ^3  on  drive  ? 
into  a  DMA  buffer  at  address  4100H. 

a.   8080  Assembly  Lanauaae 

When  writina  in  8080  assembly   languaae   MTS   is 
accessed  by  a  direct  call  to  the  MTS  entrv  ooint: 


MTS     EQU 


2000H 


mvT 

C,  12 

;FID    =    12 

MVI 

E,2 

;drive   nr 

=  2 


ia7 


CALL 

MTS 

;SELECT  DRIVE 

MVT 

C,  13 

;  F I D  =  13 

LXI 

D/4100H 

;DMA  ADDRESS  = 

CALL 

MTS 

;SET  DMA 

MVT 

C  ia 

;fid  =  14 

MVI 

E/43 

;TRACK  NR  =  43 

CALL 

MTS 

PSET  TRACK 

MVT 

C,  15 

;fid  =  15 

MVT 

E/22 

/'SECTOR  NR  =  22 

CALL 

MTS 

;SET  SECTOR 

MVI 

C,  16 

;fid  =  16 

CALL 

MTS 

;READ  FLOPPY 

4100H 


MVI 

MVI 
CALL 
MVI 
CALL 


C,  15 
E,23 
MTS 
C,  16 
MTS 


;FID  =  15 
/CHANGE  SECTOR  NR 
;SET  SECTOR 
;FID  =  16 
;PEAD  AGAIN 


b.   ML80 

The  readability  of  ML^O  source  Droarairs  may  be 
enhanced  bv  defininq  an  M  8  0  macro  for  each  call  to  MTS  used 
in  the  program.  The  followina  code  sequent  contains  several 
examcl es . 


[MACRO  UTS  »2000h"] 
[MACRO  SELECTSORIVE  DMR  ' 

C  =  12;  E  =  [DNR] ;  CALL  [MTS]'] 
[MACRO  SET5DMA  DMA  • 

C  =  13;  DE  =  [DMA];  CALL  [MTSl'l 
[MACRO  SETSTRACK  TNR  » 

C  =  14,*  E  =  [TNR];  CALL  [MTS]'] 
[MACRO  SETSSECTOR  SNR  ' 

C  =  15;  E  =  [SNR] ;  CALL  [MTS] '] 
[MACRO  READSFLOPPY  ' 

C  =  16;  CALL  fMTSl '] 


/*  SPECTFY  COMPLETE 
[SELECTSDRIVE  »2,J? 
[SETSDMA  •  a  1  00H  *  3  ; 
[SETSTRACK  »43'1 } 
ISETSSECTOR  •  22  '  ]  J 
[READSFLOPPY] ; 


SECTOR  ADDRESS  AND  DMfi  RUFFEK    */ 


/*  INCREMENT  SECTOR 
[SETSSECTOR  '23'] } 
[REAOSFLOPPY] ; 


NR  AND  READ  AGAIN  */ 


PL/M 


/A***************************************************/ 
/*        SAMPLE  PL/M  PROGRAM  SEGMENT  */ 

/♦a**************************************************/ 

aoooh: 


USER:  P 
DECLARE 
LIT 
MTS 
SEL 
SET 
SET 
SET 
REA 
DIS 


pocedupe; 


LITERALLY 

LIT 

LIT 

LIT 

LIT 

LIT 

LIT 

LIT 


'LTTFRALLY'  , 
POOOH' , 

12'  , 
13'  , 
14', 
15'  , 
16'  , 

l  '  ; 


ECTSDRTVF 

SDMA 

*TRACK 

$SECTOR 

D5FLOPPY 

PLAYSMSG 

A**********************************************/ 

*/ 


MTS  INTERFACE  PROCEDURES 


/♦A***************************************************/ 

MTS1:  PROCEDURE  (F1D,PAPM); 

/•a**********************************/ 

/*  PROVIDES  THE  MTS  INTERFACE  FOR  */ 
/*  FUNCTIONS  WHICH  DO  NOT  REQUIRE  A  */ 
/*  RETURN  VALUE.  */ 

/*  INPUT:  FID  -  MTS  FUNCTION  ID  */ 
/*  PARM  -  PARAMFTER  OP  ADDRESS*/ 
/*  OF  PARAMETER  LIST.   */ 

/a***********************************/ 
DECLARE  FID  BYTE,  PARM  ADDRESS,* 
GO  TO  MTS; 
END  MTSl; 

MTS2:  PROCEDURE  (FID, PARM)  BYTE; 

/a***********************************/ 

/*  PROVIDES  THE  MTS  INTERFACE  FOR  */ 
/*  FUNCTIONS  WHICH  REQUIRE  A  VALUE  */ 
/*  RETURNED.  INPUT  PARAMETERS  APE  */ 
/*  THE  SAME  AS  IN  MTSl.  */ 

/a***********************************/ 

DECLARE  FID  BYTE,  PARM  ADDRESS; 
GO  TO  MTS; 
END  MTS2; 
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/A***************************************************/ 
/*  SPECIFY  COMPLETE  SECTOR  ADDRESS  AND  D^A  BUFFER  */ 
/♦♦a*************************************************/ 

CALL  MTS1  (SELECTSDRIVE,  2); 

CALL  MTSKSETSDMA,  4100H); 

CALL  MTS1 (SET$TRACK,  HI); 

CALL  MTS1 (SETSSECTOR,  2?); 

/a***************************************************/ 

/*  READ  FLOPPY  RETURNS  AN  ERROR  CODE  WHICH  WILL  */ 
/*  BE  RETURNED  TO  MTS  TO  BE  DISPLAYED  ON  THF  */ 
/*  TERMINAL  STATUS  LINE.  */ 

/a***************************************************/ 

CALL  MTS1 (DISPLAYSMSG,  MTS2 (REAOSFLOPPY , 0 ) ) ; 


/*  INCREMFNT  SECTOR  NR  AND  READ  AGAIN 


*/ 


CALL  MTS1  (SETSSECTOP,  23)? 

CALL  MTS1 (DISPLAYTMSG,  MTS2 C RE AD$FLOPDY  ,  0  )  )  ; 


END  USER; 


EOF 


1  «;n 


5.   Limitations  on  User  Proarams 

MTS  was  designed  to  provide  each  user  with  his  own 
virtual  8  0  8  0  microprocessor.  Unfortunate! v*  the 
architecture  of  the  8  08  0  CPU  is  not  amenable  to  self- 
virtual  ization.  As  a  conseoupnce  several  limitations  must 
be  imoosed  on  user  orografS  runnina  in  the  MTS  environment. 
These  limitations  are: 

(1)  The  user's  memory  sDace  extends  from  address  4000H  to 
FEFF,  a  total  of  48,896  bvtes.  All  user  code,  data, 
ana  buffers  must  be  contained  within  this  area  of 
memory . 

(2)  All  user-defined  stacks  must  be  four  bytes  lonqpr  than 
the  maximum  size  reouired  bv  the  user.  The  four  extra 
bytes  are  needeo  if  an  interruot  occurs  while  the 
user's  stack  is  full.  Failure  to  crovide  this 
additional  SDace  may  result  in  random  execution  errors 
which  are  not  reproducible  and  extremely  difficult  to 
diagnose. 

(3)  User  programs  should  not  read  or  write  directly  to  T/0 
ports  while  running  under  ^  T  S  .  Terminal  and  floooy 
disk  access  is  provided  by  MTS  service  calls. 
Attempts  to  interface  directly  with  the  Sycor  '-1 40 
peripherals  or  auxiliary  storage  devices  may  interfere 
with  the  operation  of  MTS  and  damaae  other  users. 
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MTS    PROGRAM  LISTINGS 


s  tb  »j*  k'j  v>  ~±*  »j*  <y  »>  v.v  nj^  ->  *>*VM'*^'^*^  *i»  »t*  »>  »j#  *'*  o»  •.'*+jr  •  t»  •.*•  «■*  *>  «i^  v>  *£*  -j»  -.>  *•*  «i*  «.;■<  *^ «j» **»  vi» *j* *i»  vi» 4* «^  4*  ^\l*  "«t*  ,J»»v  »l--«j*  y 

^  ^»  j^  *^  ^^  #r»  «T»  *f*  «T»  *T»  *T*  "T*  *(*  'I*  *T»-"f*  *l*  *T*  'V*  *f*  *J*  •f'  *T*  *l* "T*  "T"  »r*  *V*  *T*  *T*  *T»  *T*  'T*  *f»  T*  T*  *T*  1* *V*  ^*  *T*  *V*  *t*  *t* *T*  *V*  *T*  *T* *T"  »f» *T*  "T*  «T* "1* *T* y 

/*  GLOBAL    IDENTIFIERS  */ 

S  v>  ■»!■»  ■C'  *>»  v''  «>»  *1»  *■»■  vi-  -J.-  «V  *k  *l*  *J*  "4*  *^*  ^t'  *■£*  "■!'  *+■  "-V  "4*  '•A'  '1'  *V  >t*  *>b*  *■"■  "-K  *£"  "»*  "t*1^  *t*  *i*  *i"  *+*  *i"  *J?*  *i»'  VJ*  "^  *i*  *J^  M*  *'j*  *+*  »'*  •»!*  "■'»  *V  -l*  *J*  n>  '' 

/  *Jv  ^^  *f>  »J>  »f»  «^  ^  rft  «T»  *f%  «-f*  *T*  *T*  *T*  *T*  *f"  *T*  *f*  'f*  "f*  *T*  *T*  *t*  *f*  *T*  "O  ***  *T*  "T*  *r*  *T»  *v*  'T*  'r*  ^*  *^  *T*  *T»  *T»  *T>  "T*  'l*  *r*  *T*  *|*  *<  *  *T»  "O  ^*  «T*  *T*  *T*  *T»  ^*  /^ 

/*  */" 

/*  THE  FOLLOWING  DECLARATIONS  DEFINE  SYSTEM  IDENTI-  */ 
/*  FIERS  WHOSE  SCOPE  IS  GLOBAL  THROUGHOUT  MTS.  THESE  */ 
/*    IDENTIFIERS   MAY  BE   DIVIDED    INTO   THREE  DISTINCT  */ 

/*   GROUPS.    THE   FIRST  GROUP    INCLUDES   ANY   IDENTIFIER  */ 

/*  CONSIDERED  GLOBAL-  BECAUSE  IT  IS  REFERENCED  IN  TWO  */ 
/*  OR  MORE  MODULES  OF  THE  MTS  ML80  SOURCE  PROGRAM.  BY  *• 
/^  INCLUDING  THE  DECLARATIONS  FOR  ALL  SUCH  IDENTIFIERS*/ 
/<*  IN  A  SINGLE  MODULE,  INTERMODULE  LINKAGE  IS  GREATLY  */ 
/*  SIMPLIFIED,  AND  THE  SOURCE  PROGRAMS 'S  READABILITY  */ 
/*    ATiD   CLARITY  ARE    IMPROVED.  */ 

/*  */ 

/*    THE   SECOND   GROUP    OF    IDENTIFIERS    INCLUDES   THOSE  */ 

/*  VARIABLES  T^ICH,  TAKEN  TOGETHER,  DEFINE  THE  STATE  */ 
S*    OF    THE    SYSTEM,     I.E.     THE    SYSTEM   STATE    BLOCK.     THE  */ 

/*  CONCEPT  OF  SYSTEM  STATE  IS  IMPORTANT  IN  MTS  BECAUSE*/ 
/*    THE   SYCOR  440    HARDWARE   ARCHITECTURE   PROVIDES    NO  */ 

/*  PROTECTION  AGAINST  INADVERTENT  OR  MALICIOUS  TAMP-  */ 
/*  ERING  WITH  SYSTEM  CODE  BY  USER  PROGRAMS.  TO  MINI-  */ 
/*  MIZE  THE  EFFECTS  OF  SYSTEM  CRASHES  CAUSED  BY  SUCH  */ 
/*  TAMPERING  MTS  PROVIDES  A  LIMITED  RECOVERY  CAPABIL-  */ 
/*    ITY.    AFTER  A  TASK'S   TIMESLICE   EXPIRES,    AND   JUST  */ 

/*   PRIOR  TO    INITIATING  A   NEW  TASK,    THE   MTS   MONITOR  */ 

/#  COPIES  THE  CONTENTS  OF  THE  SYSTEM  STATE  BLOCK  TO  A  */ 
/*  FILE  NAMED  . MTSRCVR.  IF  A  CRASH  OCCURS  WHILE  THE  %/ 
/*  NEW  TASK  IS  EXECUTING,  RECOVERY  MAY  BE  ACCOMPLISHED*/ 
/*    BY  REBOOTING   MTS    AND   READING   THE   CONTENTS    OF  */ 

/*    .MTSRCVR   DACK    INTO    THE    SYSTEM   STATE    BLOCK.     THE  */ 

/*    TASK   WHICH   CAUSED    THE   CRASH    IS    THEN    DELETED    AND  */ 

/*   NORMAL   OPERATION   CONTINUES.  */ 

/*  THE  THIRD  AND  FINAL  GROUP  OF  IDENTIFIERS  INCLUDES  */ 
/*   SYSTEM   DATA   ASSOCIATED   WITH   A   PARTICULAR  USER  TASK.*/ 

/*   SINCE   THIS   DATA    IS   ONLY  USED   WHEN    ITS   ASSOCIATED  */ 

/*  TASK  IS  ACTIVE,  THE  SPACE  REQUIRED  FORMS  A  SYSTEM  */ 
/*   AREA    IN   THE   TASK'S    SWAP    IMAGE.    THIS    DATA    IS   SWAPPED*/ 

/*    IN    AND   OUT  ALONG   WITH   THE   USER  AREA  OF    THE  SWAP  */ 

/*    IMAGE.  */ 

/*  */ 

/*   THE   THREE   PRIMARY    IDENTIFIER  GROUPS   DESCRIBED  */ 

/*    ABOVE   MAY   ALSO    BE   SUBDIVIDED    BASED    ON    USAGE    AND  */ 

/*   STORAGE    ALLOCATION   REQUIREMENTS.    THE   GROUP    AND  */ 

/*    SUBGROUP    HEADINGS    FOR  DECLARATIONS    IN   THIS    MODULE  */ 

/*    ARE   AS   FOLLOWS:  */ 

/*  */ 

/*                A.       GENERAL  SYSTEM  DECLARATIONS  */ 

/*                B.       SYSTEM  STATE   BLOCK  DECLARATIONS  */ 

/*                             1.       SYSTEM   CONTROL  */ 

/*                           2.       TASK  CONTROL   TABLE  */ 

/*                           3.       DISK  MAP   TABLE  */ 

/*                 C.       SYSTEM  SWAP    AREA   DECLARATIONS  */ 

/*                            1.       VIRTUAL   DISK  CONTROL   BLOCK  */ 

/*                           2.       SWAP    STACK  */ 

/•*  */ 

/*   THE   ORDER  OF   ALL   DECLARATIONS    IN   THIS    MODULE    MUST  */ 

/*    BE   MAINTAINED   TO   PRODUCE   A   PROPERLY  FORMATTED  */ 

/*   OBJECT  MODULE.     IN   THIS   REGARD   SPECIFICATION   OF   THE  */ 

/*    INITIAL.   ATTRIBUTE    IN   A  DECLARATION   MUST   BE   CONS  ID-  */ 

/*    ERED   CAREFULLY  SINCE   THE   ML80    COMPILER  ALLOCATES  */ 

/*   DIFFERENT   AREAS   OF   MEMORY  FOR    INITIALIZED   AND  */ 

/*    UN INITIAL  I ZED    VARIABLES.     SPECIAL    PRECAUTIONS    ARE  */ 

/*    ALSO   NECESSARY  FOR  LOCAL   VARIABLES    USED   ONLY    IN  */ 

/*   SINGLE   MODULES.    THE   ML80   LINK  EDITOR    IS   FORCED   TO  */ 
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/*   ALLOCATE   SPACE   FOR  SUCH   VARIABLES   WITHIN   THE  */ 

/*  MODULE'S  CODE  AREA  BY  DECLARING  EACH  SUCH  VARIABLE  */ 
/*  WITH  TYPE  DATA.  THIS  TECHNIQUES  IMPOSES  A  PENALTY  */ 
/*   OF   THREE   BYTES   PER  DECLARATION   FOR   UNNECESSARY  */ 

/*   JUMP    INSTRUCTIONS,    BUT  THE  SIMPLIFICATION   OF  */ 

/*  INTERMODULE  LINKAGES  MAKES  TEE  TRADEOFF  WORTHWHILE. */ 
/%  #/ 


/#*#*#*******   GENERAL   SYSTEM  DECLARATIONS   #********##*#/ 

/   *ft  if*  *ft  *jt  *ft  *f*  .|>  rj\  *f\  *Jv  »J*  *f%  ff%  *f+  if*  *j»  Jft  tt*  *ft  ri%  rf*  .-J*  r{\  *f%  ^JS  »,'■  Jf^  •(»  -f>  rf*  »■,■*  *f»  *f>  *fi  »J*  *T*  »}>  «,«  <^>  J|C  <fl%  *^  Jj»  »^  rjN  Jft  *Jt  ?Jt  »]»  -,\  *f\  *f>.  5|>  3ft  / 


DECLARE   PAPJK2)    BYTE    INITIAL    (0,0); 

DECLARE   DISK  BYTE    INITIAL    (0); 

DECLARE   DRIVE   BYTE    INITIAL    (0); 

DECLARE   ERROR  BYTE    INITIAL    (0); 

DECLARE   LOCK  BYTE    INITIAL    (1); 

/%   SYSTEM  LOCK  —  %/ 

/*  BIT  0:    SWAP   LOCK  -    MTS   CODE   EXECUTING  */ 

/*  BIT    l:    SPOOL   LOCK  -    SPOOLING   UNDER  */ 

/*  INTERRUPT  CONTROL  */ 

/*  BITS    2-7:       (NOT   USED)  */ 

DECLARE   TASKSTIMER  BYTE    INITIAL    ( OFFH) ; 

/*   COUNTER  RECORDING   HOW  MANY  TIMER    INCREMENTS  */ 

/*    (50M3)    REMAIN    IN   TIMESLICE  */ 

DECLARE   SVC3STACK(20)    BYTE    INITIAL    (0); 
/*    SERVICE    MODULE   STACK  */ 

DECLARE   SYSSSTACK(20)    BYTE    INITIAL    (0); 
/*    MONITOR  MODULE   STACK  */ 

DECLARE   MD3UF(512)    BYTE    INITIAL    (0); 

/*   MINI-DISK  BUFFER  -    CONTAINS   ONE   SECTOR  */ 

DECLARE   MDSAD(2)    BYTE    INITIAL    (0,0); 

/*    SECTOR  NUMBER      OF    DATA   CONTAINED    IN    MDBUF    */ 


/##*##***#*   SYSTEM  STATE   BLOCK  DECLARATIONS   *##*****#**/ 

/  2ft  *ft  +i*  2ft  Jft  J|t  Jjt  3ft  Jft  -ft  #,s  *f*  »ft  3ft  3ft  3ft  3ft 5f»  »/t  7f»  3fC  3ft  3ft  rit  *ft  rfc  3ft  ,f\  *f> »JC *ft  », .  .ft  2fC  ft*  3ft ».*  flf!  3ft  •(» *t*  »ft  -ft  3j»  3fC  3ft  rj»  3ft 3ft  ^,»  3fC  3yt  3j* 3ft / 


/****##*********#***    SYSTEM  CONTROL   ***#*#**#*#*##**#**/ 

DECLARE   TASK  BYTE    INITIAL    (0); 

/*   TERM I HAL   NR  OF   TASK  CURRENTLY  ALLOCATED  */ 

/*   TDX   CPU  -    RANGE   0-3  */ 

DECLARE   RECSFILE(2)    BYTE    INITIAL    (0,0); 

/%   MINI-DISK  SECTOR  NUMBER      OF    . MTSRCVR  */ 
DECLARE   CNFGSFILE(2)    BYTE    INITIAL   (0,0); 

/*   MINI -DISK  SECTOR  NUMBER      OF    .MTSCNFG   */ 

/#****#****#******  TASK  CONTROL  TABLE  ##*«***********#*/ 
/*  THE  TCT  CONTAINS  INFORMATION  ON  THE  STATE  OF  EACH  */ 
/*  TASK  AND  DATA  REQUIRED  TO  SUPPORT  SWAPPING.  EACH  */ 
/*  VARIABLE  CONTAINS  FOUR  ENTRIES  -  ONE  FOR  EACH  OF  */ 
/*   THE   FOUR  TERMINAL   TASKS.  */ 

/  3ft  *js  3ft  3ft  3|t  .-ft  -ft  3ft  *j»  3ft  rf*  3ft  *ft  »y-.  3ft  3!|t  3ft  3ft  *,»  »Jt  #fC  3ft  3ft  »ft  ^jt  3ft  3ft  Jf»  rS  *i»  »i»  'i"*  5ft  »f»  ^ft  *ft  »]t  «ft  *fZ  •ft  *,s  *fv  Jft  ^»  *^-.  *ft  ?J>  *j>  *ft  *<C  *t>  ^t  *f»  »ft  / 

DECLARE   TCTSSTATUS(4)    BYTE    INITIAL   (0,0,0,0); 

/*           BIT  0:    SIMULATE   BOOTSTOAP   DURING  NEXT  */ 

TIMESLICE  */ 

CALL   MCP   DURING  NEXT  TIMESLICE  */ 

(RESERVED   FOR  CASSETTE)  */ 

(RESERVED   FOR  ASYNC)  %/ 

BLOCKED   FOR  PRINTER    I/O  */ 

BLOCKED   FOR  TERMINAL    I/O  */ 

CURRENT  SWAP    IMAGE   RESIDES   ON  */ 

MINI-DISK  */ 

/*           BIT  7:    CURRENT  SWAP    IMAGE    IN   MEMORY  */ 
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/* 

/* 

BIT 

1 

/* 

BIT 

2 

/■*. 

BIT 

3 

/% 

BIT 

4 

/■*■ 

BIT 

5 

/* 

BIT 

6 

/* 

DECLARE   TCTSDM(32)    BYTE    INITIAL    ( OC0H, 0, 0, 0, 0, 0, 0, 0, 
0C0H , 0,0,0,0,0,0,0, 0C0H ,0,0,0,0,0,0,0, 
0C0H, 0,0, 0,0, 0,0,0) ; 

/%   DRIVE   MAP   -   POINTERS   TO  VIRTUAL   DISK  ASSOC-    */ 
/*    IATED   WITH   EACH  VIRTUAL   DRIVE.    BYTES   0-7  */ 

/*   CORRESPOND   RESPECTIVELY  TO   DRIVES   A-H  FOR        */ 
/*   EACH  8   BYTE   ENTRY.  */ 

/*  BITS   0-4:    DISK  NR  -    RANGE   0-31  */ 

/*  BIT  5:       (NOT   USED)  */ 

/*  BIT  6:    READ   ONLY  FLAG  */ 

/*  BIT  7:     IN   USE   FLAG  */ 

DECLARE  TCTSSIZE(4)    BYTE    INITIAL    (32,32,32,32); 
/*   SIZE   OF   SWAP    IMAGE   EXPRESSED    IN   NUMBER  */ 
/*    OF    512    BYTE   MINI -DISK  SECTORS  */ 

DECLARE   TCT3B0E(8)    BYTE    INITIAL    (0,0,0,0,0,0,0,0); 

DECLARE   TCTSEOE(  8)    BYTE    INITIAL    (0,0,0,0,0,0,0,0); 

/*   MINI-DISK  SECTOR  NUMBER      FOR  EACH  SWAP    FILE   #/ 
/*   -    INITIALIZED   WHEN   MTS   LOADED  */ 

/*****#***#:<:*###*###  DISK  MAP  TABLE  *****##***#####*#*#/ 
/*  THE  DMT  CONTAINS  INFORMATION  ON  THE  STATUS,  PRO-  */ 
/*  TECTION,  AND  LOCATION  ON  THE  MINI-DISK  OF  ALL  VIR-  */ 
/*   TUAL   FLOPPY  DISKS.    EACH   VARIABLE   CONTAINS   32  */ 

/*   ENTRIES   -   ONE   FOR  EACH   POTENTIAL   DISK  NR.    THE  */ 

/*   ENTIRE   TABLE    IS   LOADED   AND   VERIFIED   DURING   MTS  */ 

/%    INITIALIZATION.  */ 

DECLARE   DMTSFLAG(32)    BYTE    INITIAL    (0,0,0,0,0,0,0,0,0,0, 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0); 
/*  BIT  0:    DISK  EXISTS  */ 

/*  BIT    1:     IN   USE  */ 

/*  BIT  2:    PROTECTED   -    KEY  REQUIRED  */ 

/*  BIT  3:    RESTRICTED   TO   READ   ONLY  W/0   KEY      */ 

/*  BITS   4-7:       (NOT  USED)  */ 

DECLARE  DMT8B0E(64)  BYTE  INITIAL  (0,0,0,0,0,0,0,0,0, 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.0,0,0,0, 
0,0,0,0,0,0,0) ; 

/*   MINI -DISK  SECTOR  NUMBER      FOR  BEGINNING   */ 
/*   OF   EXTENT  */ 

DECLARE  DMTSE0E(64)  BYTE  INITIAL  (0,0,0,0,0,0,0,0,0, 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 
0,0,0,0,0,0,0) ; 

/*   MINI-DISK  SECTOR  NUMBER      FOR  END   */ 
/#   OF   EXTENT  */ 

DECLARE   DMTSKEY(  128)    BYTE    INITIAL    (20H); 

/*   ONE   TO   FOUR  ASCII    CHAR  PROTECTION   KEY  */ 


/*##********    SYSTEM  SWAP    AREA   DECLARATIONS    ###****#****:/ 

/    /JS  Jf>  if*  if*  f£  if>  <fc  ifs  *f*  if.  ^fV  rfi  if*  if*  ^>  if*  *{*  «f»  *fs  *f»  if*  if*  if*  if*  if*  *f*  rjZ  if*  *f*  if*  rf\  if*  *[*  if*  i(*  if*  •(*  »f*  if*  if*  <f»  if*  if*  ij*  «t*  «f*  rtf,  »j*,  •$*.  if*  Jf*  if*  if*  if*  / 


/*****:?:**##***  VIRTUAL  DISK  CONTROL  BLOCK  ****#*#*#*#**/ 
/*  EACH  USER  TASK  HAS  AVAILABLE  8  VIRTUAL  DRIVES  WHICH*/ 
/*   MAY  BE   SELECTED   TO   ACCESS   THE   ATTACHED   VIRTUAL  */ 

/*    DISK.    FOR  EACH   USER    IT    IS   NECESSARY  TO   RECORD  */ 

/*   WHICH  DRIVE    IS   CURRENTLY  ACTIVE.    AND   ADDITIONAL  */ 

/*   DATA   NEEDED   TO   MAP   A  VIRTUAL   DISK  ACCESS    INTO   A  */ 

/*  PHYSICAL  MINI-DISK  ACCESS.  ALL  THIS  INFORMATION  IS  */ 
/*  MAINTAINED  IN  THE  VDC  BLOCK.  THE  VDC  BLOCK  ASSOC-  */ 
/*    IATED   WITH  EACH  TASK    IS   CONTAINED    IN   THAT  TASKS  */ 

/*  SWAP  FILE  IN  A  SPECIAL  AREA  RESERVED  FOR  MTS  SYS-  */ 
/*  TEM  USE.  THIS  MEANS  THAT  ONLY  ONE  OF  THE  FOUR  VDC  */ 
/*  BLOCKS  MAINTAINED  BY  THE  SYSTEM  IS  EVER  RESIDENT  */ 
/*    IN   MEMORY  AT   ANY  ONE   TIME.  */ 

DECLARE    VDCSDRIVE   BYTE; 
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/*     BITS  0-2:  DRIVE  NR  FOR  DRIVE  CURRENTLY   */ 
/■*  SELECTED  */ 

/*     BITS  3-5:   (NOT  USED)  */ 

/*     BIT  6:  READ  ONLY  FLAG  */ 

/*     BIT  7:  MODIFICATION  FLAG  -  SET  WHEN  CON-  */ 
/*  TENTS  OF  BUFFER  MODIFIED         */ 

DECLARE  VDCSB0E(2)  BYTE; 

/*  MINI-DISK  SECTOR  NUMBER  FOR  BOE  OF  VIRTUAL  */ 
/*  DISK  CURRENTLY  ATTACHED  TO  SELECTED  DRIVE    */ 

DECLARE  VDC3EQE(2)  BYTE; 

/*   MINI-DISK  SECTOR  NUMBER  FOR  EOE  OF  VIRTUAL  */ 
/*  DISK  CURRENTLY  ATTACHED  TO  SELECTED  DRIVE    */ 

DECLARE  VDCSSECTOR  BYTE; 

/*  VIRTUAL  DISK  SECTOR  NR  FOR  SUBSEQUENT  */ 
/*  ACCESSES  -  RANGE  1-26  */ 

DECLARE  VDCSTRACK  BYTE; 

/*   VIRTUAL  DISK  TRACK  NR  FOR  SUBSEQUENT  */ 
/*  ACCESSES  -  RANGE  0-76  %/ 

DECLARE  VDC$DMA<2)  BYTE; 

/*  MEMORY  ADDRESS  OF  128  BYTE  DMA  BUFFER  */ 
/*  FOR  SUBSEQUENT  VIRTUAL  DISK  ACCESSES   */ 

/#*#*#*;<:##************  SWAP  STACK  ***5(c***5f:#*J(5S(c5C*sC**#**!(C5C/' 

/*  EACH  TIME  A  TASK  IS  SWAPPED  OUT  THE  CURRENT  OPER-  */ 

/*  ATING  ENVIRONMENT,  I.E.  PSW,  BC,  DE,  HL,  AND  SP,  */ 

/*  MUST  BE  SAVED  IN  A  KNOWN  AREA  SO  THAT  IT  CAN  BE  #/ 

/*  QUICKLY  RESTORED  WHEN  THE  TASK  IS  SWAPPED  BACK  IN.  */ 

/*  MTS  USES  A  STACK  IN  THE  SYSTEM  AREA  OF  THE  SWAP  */ 

/*  IMAGE  TO  HOLD  THE  ENVIRONMENT  WHEN  A  TASK  IS  #/ 

/%    INACTIVE.  */ 

DECLARE  SWAPSSTACKC 10)  BYTE; 

/%   AREA  IN  WHICH  USER  ENVIRONMENT  IS  */ 
/*  SAVED  WHEN  TASK  IS  SWAPPED  OUT     */ 

EOF 
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v  »t*  *  t*  » ■»  s>  -t-  vb»  »>•  *J»  *A»  »v  * V  N ''  ***  * V  *4*  V'  *-fr>  *•£'  ■+■  *  J*  *4*  4* *-}*  *+*  vf'  *sf*  *♦*  *•£*  *v*  **{*  *t*  *•!?  *^*  *4*  *Jr  *•  t*  ^i*  *^*  *i*  ^fr*  *4*  *£*  '4*  *4*  **i*  *V  *■  J*  ***  ^4*  *J*  "V  "i1"  » V  *M  y' 
/  ^^  ^>  ^**f*  *f»  ^  ^S  «^  «t»  »c*  n*  *7*  »f»  *r*  rfffc'T*  *?»  n*-  *r*  ■!*  *•*  *r»  •<*  •!*  *T*  *^*t»*1*  *r*  *f»  *r»  *f*  fl*  *r»  *t*  *r»  *T»  *f*  ^*  *T*  *f*  *t*  ^■*t*  *t»  ^*  *r*  "f*  *r>  ^*  «fv  *^  ^J>  *Jx  / 

/*  INTERRUPT  MODULE  */ 

••  s*»  <»>•»>  -^  v>  -■»■  -h*  *j-  »>  *>  •>  - ■»  >>  » ■»>  -4*  '■t*  *4*  *t*  *i^  *s*  ^'^y  *£?  "ir  *■/»  •■>  *4*  "^t*  *  t*  "4*  4*  "&"4e  *&  M?  *l'  ■-(■'  ■»*»»■-  '^  *i*  *-''  */*»'>  ■>•  »[*  ii>  *j*-i»  *>»>»»>.  >>•>   ,■ 

/  ^^  ^>  rf\  »f»  «T»  •»•  •T*  if*  *T*  *T*  *T*  *v*  •T'  *r*  *T*  *f*  *T*  ***  *T*  »r^  <r»  *T*  *T*  ^"  *i>  »r»  rr*  *T*  *»*  *T*  «T*  *f>  *T»  *T>  *1*  *T»  *r*  •'!'»  "T*  n"  *•*  •**  "•*  *T*  «T»  *t*  *T*  *W*  *9*  •!»  ')»  *C*  i|*  *v*  /^ 

/*  */ 

/*    ALL   HARDWARE    INTERRUPTS   ON   THE   SYCOR  440    SYSTEM  */ 

/*   CAUSE   THE   EXECUTION   OF   A   RST    1     INSTRUCTION.    THIS         */ 

/*  INSTRUCTION   BEHAVES   LIKE   A   CALL   TO   LOCATION   0G08H,    */ 

/*  I.E.    THE   PC   VALUE    IS   STACKED,    AND   CONTROL  TRANS-         */ 

/*  FERRED   TO   LOCATION   O008H.    DUE   TO   THIS   HARDWARE             */ 

/%  CHARACTERISTIC,    THE   USER  MUST  ENSURE   THAT  ANY  USER  */ 

/*  DEFINED    STACKS    ARE    AT    LEAST   FOUR   BYTES    LARGER   THAN    */ 

/■*■  THE   MAXIMUM  SIZE   REQUIRED   BY  THE   USER'S    OWN   CODE.       */ 

/*  SINCE   ALL   PERIPHERAL  DEVICES   CAUSE   EXECUTION   OF           */ 

/*  THE   SAME    INTERRUPT    INSTRUCTION,    SOME   MEANS   MUST  BE  */ 

/*  AVAILABLE  TO   DISTINGUISH  BETWEEN   DEVICES   WHENEVER      */ 

/*  AN    INTERRUPT  OCCURS.    THE   SYCOR  440   SOLVES   THIS              */ 

/*  PROBLEM   BY   DEFINING   AN    INTERRUPT    LEVEL    FOR   EACH            */- 

/*  DIFFERENT   DEVICE.    THERE   ARE    17    INTERRUPT  LEVELS            */ 

/*  WITH  VALUES   RANGING   FROM  0   TO    16.    A   HIGHER  NUMERIC   */ 

/*  VALUE   ALSO    IMPLIES    A  HIGHER   PRIORITY  FOR  THE                   */ 

/*  ASSOCIATED  DEVICE.    WHEN   AN    INTERRUPT  OCCURS   THE           */ 

/*  LEVEL    IS   AVAILABLE   ON    INPUT  LATCH   0.    SIMULTANEOUS      */ 

/*  INTERRUPTS    WILL    BE    INPUT  SEQUENTIALLY    IN    PRIORITY,    */ 

/W  I.E.     DESCENDING,     SEQUENCE    BY   LEVEL    NUMBER.     WHEN            */ 

/*  THE    LEVEL    READS    ZERO    ALL    PENDING    INTERRUPTS    HAVE         */ 

/•*  BEEN    PROCESSED.    THE    INTERRUPT   LEVEL   ASSIGNMENTS            */ 

/*  WHICH   APPLY  TO   THE   CURRENT   NPS    SYCOR  440   HARDWARE      */ 

/*  CONFIGURATION   ARE   AS   FOLLOWS:                                                            */ 

/*  */ 

/*  LEVEL                     DEVICE                                                             */ 

/-w  ^/ 

/*  16  DEBUGGER  */ 

/*  15  POWER  FAIL  */ 

/*  14  PARITY  CONTROL  */ 

/*  11  ASYNC   COMM  */ 

/*  10  TERMINAL   GROUP    0  */ 

/*  O  TIMER  */ 

/*  6  PRINTER  0  */ 

/*  2  FLOPPY  DISK  *• 

/  I  CASSETTE  */ 

/*  */ 

/*   THIS   MODULE   CONTAINS   THE   CODE   USED   BY  MTS   TO   PRO-  */ 

/*   CESS    INTERRUPTS.    THIS   CODE   CONSISTS   OF   AN    INTER-  */ 

/"*    RUPT   CONTROLLER   PLUS    A   SET   OF    INTERRUPT   HANDLER  *^ 

/*    ROUTINES    -    ONE   ROUTINE   FOR  EACH  DEVICE.    THE    INTER-  */ 

/*   RUPT  CONTROLLER  SAVES   THE   CURRENT  ENVIRONMENT,  %/ 

/*    IDENTIFIES    THE    INTERRUPT  LEVEL,    CALLS   THE   APPROP-  */ 

/*    R1ATE   HANDLER  ROUTINE,    AND   THEN   RESTORES   THE  */ 

/*   ENVIRONMENT  BEFORE   RETURNING  TO   THE    INTERRUPTED  */ 

/*   PROGRAM.    THE   HANDLER  ROUTINES   ARE   TAILORED   TO   THE  */ 

z'*    SPECIFIC    REQUIREMENTS    OF    DIFFERENT   DEVICES.     IN  */ 

/*    ORDER  TO   UTILIZE   THE   CODE   CONTAINED    IN    THE    INTER-  */ 

/*   RUPT  MODULE    IT    IS   NECESSARY  FOR  THE  MTS    INITIAL-  */ 

/*    IZATION   ROUTINE   TO   LOAD   A  JUMP   TO   THE    INTERRUPT  */ 

/*   CONTROLLER   IN   MEMORY  LOCATIONS   0008-000AH.  */ 

/*  */ 

/*  *s 
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/**##*#*###**    INTERRUPT  PROCESSING   MACROS   #*#**##**#***/ 

[MACRO   LEVEL    *IN(0)'] 

[MACRO   DEBUGS LATCH    '0FFH'] 

[MACRO   CSSTSLATCH    '85H'] 

[M4CR0   PRINTERSLATCH    '8AH'] 

[MACRO   TIMERSLATCH    '02H'] 

[MACRO   TERMINALSLATCH    '3EH'] 

[MACRO   MATRIXSLATCH    '3FH'] 

[MACRO    INTSPENDING    ' ( A= [ LEVEL] A)     !ZERO'] 

[  MACRO   DEBUGS  I NTSPEND I NG    ' ( A= [ LEVEL] ;    A : : 1 6 )    ZERO  * ] 

/****##**#******#    MODULE   DECLARATIONS    J*****************/ 

[  INT  TOP    BLINK  EP]    [BLINK:=4]    [TOP:=30]    [EP:=TOP-10] 
DECLARE    INTSSTACK  DATA   (0,0,0,0,0,0,0,0,0,0,0,0,0, 

0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0); 
DECLARE   BLINKSTIMER  DATA   (1); 
DECLARE   SAVHL   DATA    (0,0); 

/*####*#****#*:;{#.•£#:&**#    PROCEDURES    **#***#*****##*******/ 

DUMMYSBDLR:   PROCEDURE; 

/*  THIS  PROCEDURE  PROVIDES  A  COMMON  EMPTY  INTERRUPT  */ 

/*  HANDLER  FOR  THOSE  INTERRUPT  LEVELS  WHICH  SHOULD  */ 

/*  NEVER  OCCUR  WITH  THE  CURRENT  NPS  SYCOR  440  nARD-  */ 

/*  WARE  CONFIGURATION.  ITS  ONLY  ACTION  IS  AN  IMMEDI-  */ 

/*  ATE  RETURN.  */ 

/*  CALLED  BY:  INTERRUPTSCONTROLLER  */ 
/****«;;;*:;:  r;:*  *  tf  #:);#:}:::::•:*  *^ 

RETURN; 

END  DUMMYSHLDR; 

DEBUGSHDLR:   PROCEDURE; 

/*  THIS  HANDLER  IS  INCLUDED  TO  ALLOW  USAGE  OF  THE  */ 

/*  SYCOR  340B  DEBUGGER  IN  TEE  SOFT  DEBUG  MODE  WHEN  */ 
/*  RUNNING  UNDER  NTS.  IT  WAS  DISCOVERED  DURING  DEVEL-  */ 

/*  OPMENT  AND  TESTING  THAT  THE  DEBUGGER  IS  LARGELY  */ 

/*  UNRELIABLE  IN  THE  SOFT  MODE.  THIS  IS  APPARENTLY  */ 

/*  DUE  TO  HARDWARE  CHANGES  IN  THE  440  SYSTEM  MADE  */ 

/*  AFTER  THE  DEBUGGER  WAS  DESIGNED.  */ 

/*  CALLED  BY:  INTERRUPTSCONTROLLER  */ 

/*  DISPLAY  ENVIRONMENT  ON  DEBUGGER  */ 

HL=2+SP: 

M(6H)  =  (A=L);  M(7H)  =  (A=H); 

/*  ACKNOWLEDGE  DEBUG  INTERRUPT  */ 

OUT(  [ DEBUGSLATCH] )  =  (  A= 1 )  ; 

/*  CPU  IDLES  WHILE  WAITING  FOR  DEBUGGER  TO  *• 

/*  INITIATE  RESUMPTION  OF  EXECUTION         */ 

DO  WHILE  [ DEBUGS  I NTSPEND I NG] ; 

END; 
END  DEBUGSHDLR; 

CASSETTESHDLR:   PROCEDURE; 

OUT( [ CSSTSLATCH] )  =  (  A= 10H) ; 
END  CASSETTESHDLR; 

PRINTERS HDLR:   PROCEDURE; 
A= IN(  [  PRINTERSLATCH] ) ; 
END  PRINTERSHDLR; 

TIMERS HDLR:   PROCEDURE; 

/*  THE  TIMER  INTERRUPT  HANDLER  MANAGES  THE  TWO  FUNC-  */ 
/*  TIONS  OF  MTS  WHICH  OCCUR  AT  PERIODIC  INTERVALS:  #/ 
/*  BLINKING  THE  TERMINAL  CURSORS  AND  RETURNING  CONTROL*/ 
/*  TO  THE  SYSTEM  WHEN  A  TASK'S  TIMESLICE  EXPIRES.  IN  */ 
/*  ORDER  TO  KEEP  TRACK  OF  THE  TWO  INTERVALS  INVOLVED,  */ 
/*  THE  PROCEDURE  MAINTAINS  TWO  COUNTERS.  THESE  COUN-   */ 
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/*  TERS  ARE  EACH  SET  TO  AN  INITIAL  VALUE  AND  THEN  */ 
/*  DECREMENTED  EACH  TIME  A  TIMER  INTERRUPT  OCCURS.  */ 
/*  THE  ACTUAL  VALUE  CONTAINED  IN  EITHER  COUNTER  AT  ANY*/ 
/*  INSTANT  REPRESENTS  THE  TIME  REMAINING  IN  THE  INTER-*/ 
/*  VAL  IN  MULTIPLES  OF  50MS  SINCE  THIS  IS  THE  FIXED  */ 
/*  INTERVAL  BETWEEN  TIMER  INTERRUPTS.  WHEN  THE  TASKS  */ 
/*  TIMER  COUNTER  HAS  BEEN  DECREMENTED  TO  ZERO,  CONTROL*/ 
/*  IS  TRANSFERRED  TO  THE  MONITOR  WHERE  THE  CURRENT  #/ 
/*  TASK  IS  SWAPPED  OUT  AND  A  NEW  TASK  SWAPPED  IN.  */ 
/*  WHEN  THE  BL I NKST I MER  COUNTER  REACHES  ZERO  THE  */ 
/*  BLINKSCURSOR  PROCEDURE  IS  CALLED.  IN  EITHER  CASE  */ 
/#  THE  TIMER  HANDLER  RESETS  THE  COUNTER  TO  ITS  IN  IT-  */ 
/*  IAL  VALUE  AND  CONTINUES.  */ 

/*  CALLED  BY:  INTERRUPTSCONTROLLER  */ 

TASKST I  MER=  (  A=  TASKST I MER-  1 )  ; 
BL I NKST I MER=  (  A=  BL I NKST I MER- 1 )  ; 

IF  (A::0)  ZERO  THEN   /*  BLINK  INTERVAL  EXPIRED  */ 
DO; 

CALL  [ BL I NKSCURSOR] ; 
BL  I  NKST  I  MER=  (  A=  [  BL  I NK]  )  ; 
END; 
OUT([TIMERSLATCHJ)=(A=0) ;   /*  RESET  TIMER  */ 
IF  (A= TASKST I MER;  A::0)  ZERO  THEN 
DO;   /*  TIMESLICE  EXPIRED  */ 
IF  (A=>LOCK)  fCY  THEN 

DO;   /*  SWAPPING  UNLOCKED  */ 
BC= 1 0 ;  DE= . I NTSSTACKX C  EP ] )  ; 
HL=.SWAPSSTACK; 
CALL  EMOVBUF]  ; 
ENABLE; 

GOTO  [MONITOR]  ; 
END- 
ELSE  TASKST  I  MER=  (  A=  1 )  ; 
END; 
END  TIMERSHDLR; 

TERMINALSHDLR:   PROCEDURE; 

/*^:|;**^^^*:K:S^**^*****«**^"i<**^*^******«****************^/ 
/#  THIS  PROCEDURE  PROCESSES  THE  INTERRUPT  GENERATED  */ 
/*  FROM  ANY  KEY  DEPRESSION  AT  ANY  OF  THE  TERMINALS.  */ 
/*  IT  GETS  THE  TERMINAL  IDENTITY  AND  THE  KEYBOARD  */ 
/*  MATRIX  CODE  AND  THEN  CALLS  TERMINALS  I NPUTSCONTROL  */ 
/*  TO  PROCESS  THE  KEY.  */ 

/*  OUTPUT:  C  -  MATRIX  CODE  */ 

/*  E  -  TERMINAL  NUMBER  */ 

/*  CALLED  BY:  INTERRUPTSCONTROLLER  */ 

/***:^*********************  *****************************/ 

/*  READ  TERMINAL  IDENTITY  */ 

E=  (  A= IN(  I  TERMINALSLATCH1 )  03) ; 

/*  WRITE  TERMINAL  NUMBER  BACK  OUT  TO  CAUSE  */ 

/*  THE  APPROPRIATE  KEYBOARD  DATA  REGISTER  */ 

/*  TO  BE  SELECTED  FOR  READING.  */ 

OUT( [ TERMINALS LATCH] ) = A; 

/*  READ  THE  KEYBOARD  MATRIX  CODE  */ 

C= ( A= IN(  [  MATRIXSLATCH] )  )  ; 

/*  PROCESS  KEY  */ 

CALL  CTERMSINPUTSCTRL] ; 

END  TERMINALSHDLR; 


INTERRUPTSCONTROLLER:   /*  MAIN  ENTRY  INTO  INTMOD  */ 
/*  SAVE  CURRENT  VALUE  OF  STACK  POINTER  AND  */ 
/*  ALL  REGISTERS  IN  INTSSTACK  */ 

SAVHL=HL;  STACK=PSW; 
HL=2+SP;  PSW= STACK; 
SP= . INTSSTACK(  [  TOP] ) ; 

STACK=HL;   /*  PUSH  CURRENT  STACK  PTR  */ 
HL=SAVHL; 

STACK=HL;   /*  PUSH  ORIGINAL  CONTENTS  OF  HL  */ 
STACK=DE;  STACK=BC;  STACK=PSW; 
DO  WHILE  C INTSPENDING] ; 
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H=(A=0);  L= ( A= [ LEVEL] ) ; 
DO  CASE  HL; 
/*   0  */   CALL  DUMMYSHDLR; 

CALL  CASSETTESHDLR; 

CALL  DUMMYSHDLR; 

CALL  DUMMYSHDLR; 

CALL  DUMMY© HDLR; 

CALL  DUMMY® HDLR; 

CALL  PRINTERSHDLR; 

CALL  DUMMYSHDLR; 

CALL  TIMERSHDLR; 

CALL  DUMMYSHDLR; 

CALL  TERMINALSHDLR; 

CALL  DUMMYSHDLR; 

CALL  DUMMYSHDLR; 

CALL  DUMMYSHDLR; 

CALL  DUMMYSHDLR; 

CALL  DUMMYSHDLR; 

CALL  DEBUGSHDLR; 
END;  /*  CASE  */ 
END;  /*  WHILE  */ 

/%  RESTORE  ORIGINAL  VALUE  OF  STACK  POINTER  AND  */ 
/*  ALL  REGISTERS  FROM  INT3STACX  */ 

PSW=  STACK;  BC= STACK;  DE= STACK;  HL= STACK; 
SAVHL=HL;  HL= STACK; 
SP=HL;  HL=SAVHL; 
ENABLE; 
RETURN; 
/%  END  INTERRUPTSCONTROLLER  #/ 
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/*  MONITOR  MODULE  */ 

/  \v  ■"ifc'  *dr  *J*  *>•  "J*  »J»  "V  «J*  *4»  *>  « ►•  "»i*  *  !•*  *^  ^^  *i*  ~t*  •J'  ^V  ^  "»K  *.'*  "-I*  *£*  *i*  "i*  *^  ■*>*  ••*  *^»  *4f  *1*  *4>  *i*  ^i*  *4*  ^A'  *(*  *  '*  *i*  "A*  *^  *J*  *A*  *J*  */*  *J*  "4-*  \I*  '■J'  *>^  ^t*  ^i>  / 

/  *^  *^  .^*  ^>  -^  *^  «T*  «^  ^  *^  *^  «"^  «^  *f*  ^S  «T*  *T*  *T*  *^  n*  *T*  *r»  *i*  *&  -T*  *T*  T*  "T*  "T*  *T»  *f*  ^*  "T*  "T*  *|*  *•*  "t*  *T*  *r*  *T*  "T*  *0  <T*  *1^  "T*  ***  •T*  *i*  *f*  fl*  ^»  »T*  *T*  *T>  / 

/#  */ 

/*  THE   MONITOR   MODULE   CONTAINS    THOSE    FUNCTIONS    OF    MTS  */ 

/*  WHICH   DEAL   WITH  PROCESSOR  MANAGEMENT.    SUCH   FUNC-  */ 

/*  TIONS    INCLUDE  THE    INITIAL   PROGRAM  LOAD,    SYSTEM  */ 

/*  RECOVERY,    SCHEDULING,    CPU  ALLOCATION,    AND   SWAPPING.*/ 

/*  THE   MODULE    IS   DIVIDED    INTO  THREE   BASIC   SUBMODULES.  */ 

/#  */ 

/*  (1)    UTILITY  PROCEDURES  */ 

/*  THIS    SUBMODULE    CONTAINS    GENERAL    PURPOSE  */ 

/*  UTILITY  PROCEDURES   WHICH  PERFORM  OPERATIONS  */ 

/*  FREQUENTLY   REQUIRED    IN   THE   MONITOR,     INTERRUPT  */ 

/*  AND   SERVICE   MODULES.  */ 

/*  *    INDEX                                 *   PUT  */ 

/*  *    INDEX2                               *   GET  */ 

/*  *    INDEX4                                  *    MOVBUF  */ 

/*  *    INDEX8                                *    MINISDISK  */ 

/*  */ 

/*  (2)    TASK  MANAGEMENT  */ 

/*  THIS   SUBMODULE   CONTAINS   THE   SCHEDULING,    CPU  */ 

/*  ALLOCATION,    AND   SWAPPING   PROCEDURES.     IT  ALSO  */ 

/*  INCORPORATES    THE   MECHANISM  FOR  RECORDING   THE  */ 

/*  SYSTEM  STATE    BLOCK   WHEN    THE    SYSTEM   STATE  */ 

/*  CHANGES,    THUS    MAKING   RECOVERY  POSSIBLE.  */ 

/*  CONTROL   PASSES    TO   THE   TASK  MANAGEMENT  */ 

/*  SUBMODULE   AFTER  MTS   HAS    BEEN    INITIALIZED   BY  */ 

/*  THE    I PL  SUBMODULE.  */ 

/*  *   MONITOR                            *   SWAP  */ 

/%  *    BUMPSTASK                        *    ¥RITE!?REC  */ 

/*  *    BOOTSTRAP                          *    RESUMESEXECUTION  */ 

/%  */ 

/*  (3)     INITIAL   PROGRAM  LOAD  */ 

/*  THIS   SUBMODULE   CONTAINS   ALL   PROCEDURES   WHICH  */ 

/*  DEAL   WITH  THE   LOADING   PROCESS   AFTER  THE   MTS  */ 

/%  OBJECT   MODULE   HAS   BEEN   LOADED    INTO   MEMORY  BY  */ 

/*  THE   SYCOR   SYSTEM   LOADER.     THE    PRIMARY   FUNCTION  */ 

/*  OF    THE    I PL   SUBMODULE    IS    SYSTEM    INITIALIZATION  */ 

/*  OR  RECOVERY,    AS   REQUIRED.     IN   ORDER  TO   MINI-  */ 

/*  MIZE   THE   MEMORY  REQUIREMENT   OF    THE   RESIDENT  */ 

/*  MTS   CODE,    THIS   SUBMODULE   WAS    WRITTEN   AS   A  */ 

/*  STANDALONE   PROGRAM  LOADED    INTO   THE   USER  SWAP  */ 

/*  AREA.    ONCE    IPL    IS   COMPLETE   THE   PROGRAM  MAY  */ 

S*  BE    OVERLAYED    BY   USER   PROGRAMS.  */ 

/*  *    ABORTS  I PL                         *    READSD I RECTORY  */ 

/*  *    SEARCHSD I RECTORY      *    RECOVER  */ 

/*  *    INITIALIZE                     *   MTSSIPL  */ 

/*  */ 

/*  THE   MONITOR  MODULE   REQUIRES   ACCESS   TO   SEVERAL  */ 

/*  FILES    WHICH   RESIDE   ON   THE   MINI-DISK    IN   SYCOR  */ 

/*  FORMAT.     THESE   FILES    AND    THEIR   FUNCTION    ARE:  */ 

/*  */ 

/*  ( 1 )     . MTSSWP0 , . MTSSWP 1 , . MTSSWP2 , . MTSSWP3  */ 

/*  ASSOCIATED   WITH  EACH  OF   THE   FOUR  TERMINAL  */ 

/*  TASKS    IS   A  FILE   USED  TO   STORE   A  CORE    IMAGE  */ 

/*  OF   THE  TASK  WHEN    IT    IS    INACTIVE   OR  BLOCKED.  */ 

/*  THIS    SWAP    IMAGE    CONSISTS    OF    A   SYSTEM   AREA  */ 

/*  WHERE   THE   ENVIRONMENT   AND   VIRTUAL   DEVICE  */ 

/*  CONTROL   BLOCK    IS   STORED,    AND   A  USER  AREA  */ 

/*  CONTAINING  THE   USER  PROGRAM'S   MEMORY    IMAGE.  */ 

/*  THE   MAXIMUM  SWAP    IMAGE   SIZE    IS   48K  BYTES.  */ 

/*  THEREFORE,    EACH  SWAP   FILE   SHOULD   NORMALLY  BE  */ 

/*  96    MINI-DISK  SECTORS   LONG.     IN   THE   EVENT  THAT  */ 

/*  MINI-DISK   SPACE    IS    LIMITED    AND   THE    ENTIRE    48K  */ 

/*  IS    NOT   REQUIRED   FOR  USER  PROGRAMS,    MTS    WILL  */ 

/*  AUTOMATICALLY  ADJUST  TO   ANY  FILE   SIZE   GREATER  */ 

/*  THAN    I6K   (32   SECTORS).    THE   FOLLOWING  SYCOR  */ 

/*  COMMAND   MAY  BE   USED   TO   CREATE    A   SWAP    FILE:  */ 

/*  CREATE   <FILENAME>    N=96  */ 

/*  THE   SYCOR  SYSTEM  DOES   NOT  ALLOW  DYNAMIC  */ 

/*  CHANGES    IN    FILE    SIZE    OR   ATTRIBUTES;    THUS,     IN  */ 
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/*  ORDER  TO   CHANGE  THE   FILE   SIZE,    THE  FILE   MUST  */ 

/*  FIRST  BE  DELETED    (DELETE   <  FILENAMES    AND   THEN  */ 

/*  RECREATED   WITH  THE   DESIRED   SIZE.     IF   SWAP  */ 

/*  FILES   SMALLER  THAN  48K  ARE   DESIRED,    THE   VALUE  */ 

/-*  OF    N    IN    THE    CREATE    COMMAND    STRING    SHOULD    BE  */ 

/*  TWO   TIMES   THE   REQUIRED   PROGRAM  SPACE    IN  */ 

/*  KILOBYTES.  */ 

/%  THE   FOUR  SWAP   FILES   ARE   ONLY  REQUIRED   WHEN  */ 

/*  MTS    IS   ACTUALLY  RUNNING.    OR  BETWEEN   RUNS    IF  */ 

/*  RECOVERY  WILL   BE  REQUESTED.  */ 

/*  */ 

/*       (2)     .MTSCNFG  */ 

/*  THE   VIRTUAL   FLOPPY  DISK  CONFIGURATION   FILE  */ 

/*  PROVIDES   THE   MAPPING   BETWEEN   THE   VIRTUAL  DISK  */ 

/*  NUMBER   (0-31)    AND   THE   NAME   OF   A   SYCOR  FILE  */ 

/*  WHICH  CONTAINS   A  FLOPPY  DISK    IMAGE.    THE   CON-  */ 

/*  FIGURATION   FILE   ALSO   CONTAINS   THE   PROTECTION  */ 

/*  ATTRIBUTES   OF   THE   VIRTUAL   DISKS.    WHERE  A  */ 

/*  PHYSICAL    FLOPPY   DISK  HAS    A   FIXED    CAPACITY   OF  */ 

/*  256K  BYTES,    AN   MTS    DISK    IMAGE   MAY  HAVE   ANY  */ 

/*  CONVENIENT  SIZE.    THE   SYSTEM  ASSUMES   THAT  THE  */ 

/*  DISK    IMAGE    IS   STORED   SEQUENTIALLY  ON   THE  */ 

/*  MINI-DISK  STARTING   WITH  TRACK  0   SECTOR    1    AND  */ 

/*  PROCEEDING  THROUGH  26   SECTORS   OF   TRACK  0   TO  */ 

/*  TRACK    1    SECTOR   0,    ETC.     SPECIFYING    A    VIRTUAL  *S 

/*  DISK   FILE    SMALLER  THAN    25«8K   BYTES    MEANS    THAT  */ 

/*  FEWER  THAN   77    TRACKS    WILL   BE   ADDRESSABLE,  */ 

/*  WHILE   A   SIZE   GREATER  THAN   256K  BYTES   WILL  */ 

/*  MAKE   MORE   THAN    77    TRACKS    ADDRESSABLE,    UP    TO  */ 

/*  A   MAXIMUM  OF    256    TRACKS.     IN    EITHER  CASE   MTS  */ 

/*  AUTOMATICALLY  ADJUSTS   THE   UPPER  BOUND   BASED  */ 

/*  ON    THE    FILE    SPACE    AVAILABLE.  */ 

/*  THE   CONFIGRATION    FILE  CONTAINS    32    THIRTEEN  */ 

/*  BYTE    RECORDS    IN   THE   FOLLOWING   FORMAT:  */ 

/*  #/ 

/*  I    FILENAME    I    KEY    I    P     I  */ 

/*  #/ 

/*  0  7    8       1112  */ 

/*  TVHERE    'FILENAME'     IS    THE    0-8    BYTE   NAME   OF    THE  */ 

/*  VIRTUAL   DISK  FILE   AS    IT   APPEARS    IN   THE   SYCOR  */ 

/*  DIRECTORY;     'KEY'     IS   A   0-4    BYTE   PROTECTION  */ 

/*  KEY;    AND    'P'     IS   THE  PROTECTION   ATTRIBUTE  OF  */ 

/*  THE   DISK,     I.E.     'P'    FOR   READ/WRITE   PROTECTION,  */ 

/*  'R'    FOR  WRITE   PROTECTION   ONLY,    AND   BLANK  FOR  */ 

/■*■  NO    PROTECTION.  *• 

/*  THE   CONFIGURATION   FILE   WILL   BE   UPDATED   BY  THE  */ 

/*  MTS   SYSTEM  COMMANDS   PROTECT,    UNPROTECT,    AND  */ 

/*  RESTRICT.    ALTERNATIVELY,     IT   MAY  BE   MODIFIED  */ 

/*  USING  SYCOR' S   DATA  ENTRY  FREE   FORM  MODE.     IN  */ 

/*  THE   EVENT   THAT    .MTSCNFG    IS    ERRONEOUSLY  */ 

/*  DELETED,    THE   FILE   MAY  BE   RECREATED   BY  USING  */ 

/*  THE   SYCOR   COMMAND  */ 

/*  RUN   RESTORE   2=/CSST  */ 

/*  WITH  THE   CASSETTE   LABELED    ".MTSCNFG  DUMP"  */ 

/*  MOUNTED   ON   THE   CASSETTE   DRIVE.  */ 

/*  */ 

/*      (3)     .MTSRCVR  */ 

/*  THE  RECOVERY  FILE   CONTAINS   A  COPY  OF   THE  */ 

/*  SYSTEM   STATE    BLOCK   AS    OF    THE    LAST   SWAP.    THE  */ 

/*  FILE    IS   ONLY  REQUIRED    WHEN   MTS    IS    ACTUALLY  */ 

/*  RUNNING,    OR  BETWEEN   RUNS    IF   RECOVERY  WILL  BE  */ 

/*  REQUESTED.    THE   FOLLOWING  SYCOR  COMMAND    IS  */ 

/*  USED   TO   CREATE   THE   FILE:  */ 

/*  CREATE    . MTSRCVR  N= 1  #/ 

/*.  *./■ 

S  rfZ  »i»  *p *J»  *fC  »r»  *f!*JC5f>  ijC-jI^  Jf»  3fC  if%  *ft  »,■*  -f"  *fl  -jC  »,C  if*  *;Z  if^  ^f»  -P  "ifi  ?jC  JtC  JfC  If*  •,s5fwj»  *I*  »|*  !f*5p  *K  «JC*^3|» «j^5f» tj£  5fC5fC5fC  5fC  5f£  jp  3f!2j*5jC/ 

,"  -'.•  *'r  *.L-  -sL.  *L»  O,^^  »>■■■[-  »:*  *t*  »>  •  fc*  »!••->'«*-•»>  -Jj-  vt»  ■J*  v>  »i*  Vl*  *1*  vl#  vl»  *  >f  •  [y  -Is  •*■*  vl*  «V  'lr  •(*  v^-  »>-V  *J-  «+•  - 1>  *£»•■>  *L«  «■*»'>  «i^  >>  \Lr  »1*  v>  »J»  »>  -I*     / 
r     *%*  *f*  'JH  "T*  *T"  *f*  *T*  'r*  *f*  *v*  *f*  *T*  *f*  «t*  *f»  *T*  *•»  «T*  *T*  *T»  *!*  «f*  *"?*  "T*  *T*  *T»  *f*  *t»  *P«  «T»  »r»  *T*  *o  »l  *  *V»  *(*  "f*  'r*  *T»  »r»  *J*  "T*  *T*  -*T*  «f»  *f*  ^S  *f*  "T*  *r»  *r»  *T*  "T*  'I*  ^ 
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Z*****:*::*:***********    TASK  MANAGEMENT  »#********###***#*#/ 

/^  Jji  ifC  ^|C  ^fC  JjC  5fC  Jt*  JfC  ^fC  ^t .  ifC  -JC  ^ji  5fC  5fC  ifC  5ft  *,»  *fC  ^fC  5fi  ^fC  JjC  ^J*  »|I  l^C  JfC  ^C  ?fC  5fC  ^»  5f<  ^jC  JfC  J|h  5jC  JfC  JfC  ^fC  Jf^  *;C  5p  IjC  *;t  ^C  ?j^  ^iC  5fC  ^  5fC  *,C  5r^  5fC  ^fC  y' 


/sis**:*:*********    INTERMODULE    LINKAGE    MACROS    ##***********/<' 

[INT  TB   M2B]    [TB:  =  1000H]    [M2B:=060OH3 

[MACRO   MCP    • 1A00H'] 

[MACRO   MTS    '  IF00H'] 

[MACRO    INDEX    '[HEX  M2B   +   3H]  '  ] 

[M\CRO    INDEX2    '[HEX  M2B   +    ODH]  '  ] 

[  MACRO    INDEX8    '  [  HEX  M2B   +    24H1 ' ] 

[  MACRO   GET    ' [ HEX  M2B   +    38H]  ' ] 

[MACRO   MINISDISK    '[HEX  M2B   +    54H]  '  ] 

[ MACRO   MTSSMSG    '  [  HEX  TB   +    837H] ' ] 

[MACRO    READSTERMINAL    '[HEX  TB    +    8DCH]  *  3 

[  MACRO   GETSTERMSSTATUS    '  [  HEX  TB   +    2F9H] ' ] 

/sic********:,******   GENERAL   PURPOSE   MACROS   #**#**##*****#*/ 

[ INT  MENS BASE   TOP   TIMESLICE] 

[MEMSBASE:=4O00H]       [  TIMESLICE: =4]       [TOP: =20] 

[  MACRO   SSBSBASE    ' TASK' ] 

[MACRO   SWAPSBASE    '  VDCSDRIVE'  3 

[  MACRO   READ    ' 1 ' 3 

[MACRO    WRITE    '2' 3 

[MACRO    BUMP    '-2' 3 

[ MACRO   D ISKSERROR    '  (  A:  : 0)     ! ZERO ' 3 

[MACRO   HARDWARESERROR    '8' 3 

[MACRO    INPUTSWAITING    ' OFFE' 3 

[  MACRO    IN    ' [ READ] ' 3 

[MACRO   OUT    '[WRITE]'] 

/##***:,<:#***##***«    MODULE   DECLARATIONS    is****************/ 

DECLARE    (MONITOR,    BOOTSTRAP,    RESUMESEXECUTION)    LABEL; 
DECLARE   DIR  DATA   (0); 
DECLARE   SAVHL   DATA    (0,0); 
DECLARE    I    DATA    (0); 
DECLARE   TN    DATA    (0)  ; 

/*****:(j^:**y:*>»:^:f;***^*^*    PROCEDURES    JS**************:.*:***:!:*:/ 

BUMPSTASK:       PROCEDURE; 

/*   THIS   PROCEDURE   DELETES   A  TASK  FROM  THE   SYSTEM  WHEN   */ 
/*    AN    IRRECOVERABLE   MINI-DISK  ERROR  OCCURS.  */ 

/*   CALLED  BY:    SWAP,    BOOTSTRAP  */ 

C=[BUMP3;    CALL    [MTS3; 

E=  [  HARDWARESERROR] ;    CALL    [ MTSSMSG3 ; 

END   BUMPSTASK; 

SWAP:       PROCEDURE; 

/  >i*  \i*  *i*  *i?  "4*  *£*  *tf  **"  "i-"  *i?  vi*  4*  "•!.'  *i*  'i'  ">  *J*  *i*  *fc*  *t?  'if  -if  "i*  "st*  "i'  *^  »  >  W  «.  M  i'»  *1-  -'«■  »J»  «i»  «4»  *V  »1*  »  y  -ii»  •..'*  -Ir  *i»  »J *  virf  «,',.  * '»  v*y  -0-  «!•  »[<•  «U  <ii»  O*  x£»     / 
^     ^S  ^x  *f.  »■>  -7-.  fj\  ,-K  »f»  *f*  jfk  *f»  »f>»  *f»«f»  yf»  *f»  »f»  *f*  .^  .^  ^»  rff»  »y»  /J ■.  -J*  »f»  ^f»  »f*  .-,•»  *f»  'f-.  »|»  <f»af*  *^  #|n  r^t  r[\  «fl  »f»  »f»  *^  «^  *T»  »f»  if*  »f»  *f»  »f»  *^  «jv>  Jf*  »j-  -f>  ^ 

/*   THIS   PROCEDURE   SWAPS   A  TERMINAL   TASK  BETWEEN   MEMORY*/ 

/"*   AND   THE   APPROPRIATE   MINI-DISK  SWAP   FILE.    THE   DIR-  */ 

/*    ECTION    OF    THE   SWAP,     I.E.     IN    OR   OUT,     IS    DETERMINED  */ 

/*    BY  THE   VALUE   OF    THE    VARIABLE   DIR.    THE  */ 

/*    PROCEDURE   ALSO   MODIFIES   TCTSSTATUS    TO   REFLECT   THE  */ 

/*   CURRENT  LOCATION   OF   THE  SWAP    IMAGE.  */ 

/*    INPUT:    DIR  -    DIRECTION   OF   SWAP  */ 

/*                                         1    =     IN  */ 

/*                                        2    =    OUT  */ 

/-*    CALLED    BY:     MONITOR  */ 

/*    SET    I    TO   SWAP    IMAGE   SIZE   */ 

DE= .TCTSSIZE;    A=TASK;    CALL    [INDEX]; 

I=(A=M(HL))  ; 

/*   MODIFY  TCTSSTATUS   */ 

HL= . TCTSSTATUS+BC ; 
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M(  HL)  =  (  A=  M(  HL)    \\   0C0H)  ; 

/*    SET   UP    REGISTERS    FOR  DATA   TRANSFER   */ 

DE=.TCTSBOE;    A=TASK;    CALL    C  INDEX2] ;    CALL    [  GET] ; 

DE= . [ SWAPSBASE]  ;    A= I ; 

DO   WHILE    (A::0)     !ZERO; 

L=(A=DIR);    CALL    [MINISDISKI; 
IF    [DISKS ERROR]    THEN 

DO;      /*   BUMP   TASK  OFF   SYSTEM  */ 
CALL   BUMPSTASK; 

IF    (A=DIR;    A:: [IN])    ZERO   GOTO   MONITOR; 
RETURN; 
END; 
BC=  BC+ 1 ;    DE= ( HL=  200H+DE) ; 
I=(A=I-1); 
END;       /*   WHILE   */ 
END   SWAP; 

WRITESREC:       PROCEDURE; 

/  rfZ  yfC  *f»  *fi  5fC  *JZ  *fi  rj>  ?j»  *J*  tj\  .-,»  ?f»  ^  JfC  *fs  rffi.  Tfs.  7jZ  *f+  7f*  rf*  rfc  *^  ?fv  Jf»  *fc  5j>  3(^  7fZ  Jf*  rfZ  *jZ  »J%  tf\  .(»  rjs  Jp  *fZ  *fs  *f»  *■,»  «t*  »f*  3f*  tf*  ^P  JjJ  ?fC  «f-  ffZ  5fC  3p  JjC  / 

/*  THIS  PROCEDURE  COPIES  THE  CONTENTS  OF  THE  SYSTEM  */ 
/*   STATE   BLOCK  TO   THE   RECOVERY  FILE.    THE   VARIABLE  */ 

z'*  REC3FILE  MUST  BE  SET  TO  THE  FILE'S  SECTOR  ADDRESS  */ 
/*    BEFORE   CALLING  WRITESREC.  */ 

/*   CALLED   BY:    BOOTSTRAP,    RESUMESEXECUTION  */ 

/**:K**:fc:K#***:S#:fc*£**&:fc*:f:#****^^ 

BC=(HL=RECSFILE) ;    DE= . C SSBSBASE] ; 

L=CWRITE];     CALL    [MINISDISK]; 

IF    [DISKSERROR]    THEN    HALT; 

END   WRITESREC; 

MONITOR: 

/*   THIS   ROUTINE    IS   THE   TASK  MANAGER  OR  SCHEDULER  */ 

/*   WHICn  CONTROLS   THE   ALLOCATION   OF   THE   CPU  TO   COM-  */ 

/*   PETING   TERMINAL   TASKS.       IT  PERFORMS   THIS   FUNCTION  */ 

/*    BY  SEQUENTIALLY  SCANNING  THE   TCTSSTATUS    BYTE  */ 

/*    ASSOCIATED   WITH   EACH  TERMINAL   LOOKING   FOR  A   TASK  */ 

/*    REQUIRING   THE    CPU.       THE    EFFECT   PRODUCED    IS    THAT  */ 

/*    OF    A   ROUND- ROB IN   SCHEDULING   ALGORITHM.       WHILE   THE  */ 

/*    MONITOR    IS    LOOPING,     IT    INITIATES   SWAPPING   AND  */ 

/*   PRINTING  OF   SPOOLER  FILES   AS   REQUIRED.  */ 

/%   CALLED   BY:    MTSSIPL,    MTS    (SVCMOD)  */ 

SP=.SYSSSTACK(  [TOPI) ;       /*    SET  STACK  POINTER  */ 

/*    LOCK  OUT   SWAPPING    */ 

LOCK=(A=LOCK  \    01H); 

/*    INITIALIZE   TEMP   TASK  COUNTER  */ 

TN=(A=TASK)  ; 

LOOP:       /*   SEARCH  FOR  READY  TASK  */ 

TN=(A=TN+1,S03H)  ;    /%    INCREMENT  TASK  NUMBER  */ 
/*   TEST  FOR    INACTIVE   TASK  */ 
DE=  .  TCTSSTATUS ;    CALL    [  INDEX]  ;    A=M(HL); 
IF    (A::0)    ZERO   GOTO   LOOP; 
/"*    TEST   BIT   0    -    BOOTSTRAP    LOAD    *• 
IF    (A=>A)    CY  THEN 
DO; 

DE=. TCTSSTATUS;    A=TASK;    CALL    [INDEX]; 
IF    (A=<M(HL))    CY 

(B=(A=TN);    A=TASK-B)     IZEROTHEN 

DO;    DIR=(A=[OUT]) ;    CALL   SWAP;    END; 
TASK=(A=TN)  ; 
GOTO   BOOTSTRAP; 
END; 
/*    TEST   BIT    1    -    MCP    */ 
IF    (A=>A)    CY  THEN 
DO; 

A=TASK;    STACK=PSW;       /*   SAVE   OLD   TASK  NR  */ 
TASK=(A=TN);    CALL    [MCP]; 
DE= . TCTSSTATUS ;    A=TN;    CALL    [INDEX]; 
M(  HL)  =  (  A=M(  HL)       0FDH)  ; 

/*    RESET  BIT    1    #/ 
PSW=  STACK;    TASK=A; 
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/*   RESTORE   OLD   TASK  NR  */ 
TN= ( A=TN- 1 , 803 H) ;    GOTO   LOOP ; 

/*   CONTINUE   WITH  TASK  AFTER  */ 
/*   SYSTEM  CALL   PROCESSED  */ 

END; 
/#   SKIP    BIT   2   -    RESERVED   FOR  CASSETTE   */ 
A=>A; 

/*    SKIP    BIT   3    -    RESERVED    FOR   ASYNC    */ 
A=>  A* 

/*   SKIP    BIT  4    -    BLOCKED   FOR  PRINTER    I/O    */ 
A=>  A; 

/*   TEST  BIT  5   -   BLOCKED   FOR  TERMINAL    I/O   */ 
IF    (A=>A)    CY  THEN 
DO; 

A=TN;    CALL   [GETSTERM3STATUS] ; 
IF    (A: :[ INPUTSWAITINGI)    ZERO   THEN 
DO;    /*    NO    LONGER  BLOCKED    */ 
DE=  .  TCTSSTATUS ;    A=TASK;    CALL    [INDEX]; 
IF    (A=<M(HL))    CY 
8    (B=(A=TN);    A=TASK-B)     !ZERO   THEN 

DO;    DIR=(A=[OUT] ) ;    CALL   SWAP;    END; 
TASK=(A=TN)  ; 

DIR=(A=[ IN]) ;    CALL   SWAP; 
CALL   CREADSTERMINAL] ; 
SWAPSSTACK(  1)=A; 

/-*    RETURN    CHAR   REQUESTED    #/ 
DE= . TCTSSTATUS ;    A=TASK;    CALL    [INDEX]; 
M(  HL)  =  (  A=  M(  HL)       0DFH)  ; 

/*   RESET  BIT  5    */ 
GOTO   RESUME3EXECUTI0N; 
END 
ELSE   GOTO   LOOP; 
END; 
/*    TEST   BIT   6    -    RESUME    EXECUTION    -    FM   DISK   */ 
IF    (A=>A)    CY  THEN 
DO; 

DE=  . TCTSSTATUS ;    A=TASK;    CALL    [INDEX]; 
IF    (A=<M<HL)>    CY  THEN 

DO;     DIR=(A=[OUT]) ;     CALL    SWAP;     END; 
TASK=(A=TN)  ; 

DIR=(  A=[  IN] )  ;     CALL    SWAP; 
GOTO   RESUMESEXECUTION; 
END; 
/-*    BIT   7    SET   -    RESUME    EXECUTION    -     IN    MEMORY  */ 
GOTO    RESUMESEXECUTION; 
/*   END   MONITOR  */ 

BOOTSTRAP : 

/  4?  *$C  *&?*i?  ti£  ^fc  tit  tit  *lt  *t*  l£*  *fc  ^f"  tit  *lf  tit  tit  tti  ^t  tit  *J^  *i*  *i*  ^f  vl*  H£  t*it  vJ^  ij£  ^i*  *&£  *4"*  *J*  *(*  4?  Sf  ^it  tit  ^t  tit  i*J  ifc  *fc  Sf  ^*  ifc  S^ii?  *if  1<J  ^f  t&.  iJf  St  / 

/*  THIS  ROUTINE  EXAMINES  THE  DISK  MAP  FOR  THE  CURRENT  */ 
/*  TASK;  DETERMINES  THE  VIRTUAL  DISK  ATTACHED  TO  DRIVE*/ 
/*   A;    LOADS   THE   FIRST  512   BYTES   FROM  THE   DISK    INTO  */ 

/*    MEMORY  STARTING    AT   THE    BASE    OF    THE    USER  SWAP    AREA;    */ 
/*   AND   THEN   TRANSFERS   CONTROL   TO   THE   CODE   JUST   LOADED.*/ 
/*******^***^******^***^^:S**^*V;****************y:*******/ 
/*   DETERMINE   DISK  NR  ATTACHED   TO   DRIVE   A  */ 
DE=.TCTSDM;    A=TASK;    CALL    [ INDEX8] ; 
A=M(HL)       1FH; 

/*   DETERMINE   BOE   FOR  DISK  */ 
DE=.DMTSBOE;    CALL    [ INDEX2] ;    CALL    [GET]; 
/*    READ    FIRST   SECTOR  ON    VIRTUAL   DISK   */ 
DE=  [  MEMSBASE]  ;    L=[READ];    CALL    [MINISDISK]; 
IF    [DISKSERROR]    THEN 

DO;       /*   BUMP   TASK  OFF   SYSTEM  */ 
CALL   BUMPSTASK; 
CALL   WRITESREC; 
GOTO   MONITOR; 
END; 
/*   UPDATE   SYSTEM  STATUS   */ 
DE= . TCTSSTATUS ;    A=TASK;    CALL    [INDEX]; 
A=M(HL)    N    BOH;       /*    SET   BIT   7    *s 
M(HL)  =  (A=A      0FEH)  ;       /*    RESET   BIT   0    */ 
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CALL   WRITESREC; 

TASKST I  MER=  (  A=  [  T I MESL I CE]  )  ;       /*    RESET  TASKST I  PIER  */ 

LOCK=(A=LOCK     0FEH)  ;       /*   UNLOCK  SWAPPING  */ 

SP=0FEFFH; 

GOTO    [ MEMSBASE] ; 

/*   END   BOOTSTRAP   */ 

RESUMESEXECUTION: 

/*   THIS    ROUTINE   TRANSFERS    CONTROL   BACK  TO   A  USER  TASK  */ 
/*   WHICH  HAS   BEEN   SWAPPED    INTO   MEMORY.  */ 

CALL   WRITESREC; 
/*    UPDATE   SYSTEM  STATUS   */ 

TASKSTIMER=(A=CTIMESLICE]) ;       /*   RESET  TASKSTIMER  */ 
S*   RESTORE   ORIGINAL    VALUE    OF    STACK  POINTER   */ 
/*    AND   ALL   REGISTERS   FROM  SWAPSSTACK  */ 

SP=.SWAPSSTACK; 

PSW= STACK;    BC= STACK;    DE= STACK;    HL= STACK; 
SAVHL=HL;    HL= STACK; 

SP=HL;    HL=SAVHL;       /*   RESTORE    USER  SP    */ 
STACK=  PSW* 

LOCK=(A=LOCK      OFEH) ;       /*   UNLOCK  SWAPPING   */ 
PS W= STACK; 

RETURN;    /%    RETURNS    TO    INTERRUPT   POINT  */ 
/*     IN    USER   SWAP     IMAGE  */ 

/*    END   RESUMESEXECUTION    #/ 


EOF 

/if.****************   UTILITY  PROCEDURES   **##*#**#**##****/' 

/*    #f?  •(C  ?f>  »fC  *^-»  *f»  .Js  <lpt  r\-+  r(%  rjZ  rf*  <J>  ?]C  rf\  *(■»  rJS  »f^  rf»  Jf*  *J»  *f>  JJ*  i-f>  r]S  #J*  <j>  rfc  rfi  »j»  rfZ  <jC  «f«  «}-«  »{»  «J>  *^  ^Js  if*  ^f>  Jf»  *,■»  *J>  »j^  *(*•  Jp  *f»  3p  Ifi  »0  *T*  Sp  ^R  *K  f 


INDEX:       PROCEDURE; 

/*    GIVEN    THE    BASE    ADDRESS    OF    A   BYTE    VECTOR   AND    AN  */ 

/*    INDEX  VALUE,    THIS    PROCEDURE  CALCULATES    THE    ADDRESS  */ 

/*    OF    THE    INDEXED   ENTRY.  #• 

/*    INPUT:       A  -    INDEX  VALUE   (USUALLY  TASK)  *• 

/*                      DE   -    BASE   ADDRESS   OF    VECTOR  */ 

/*   OUTPUT:    BC   -    INDEX  VALUE  */ 

/"*                          DE    -    SAME    AS    INPUT  */ 

/*                        HL   -    CALCULATED   ADDRESS   OF    INDEXED   ENTRY  */ 

/*    CALLED   BY:    SWAP,     MONITOR,    VALSDISK,    CLEARSFLAG,  */ 

/*                               ATTACH,    LOGIN,    QUIT,    SIZE,    TERMSBLOCK,  */ 

/*                               SELECTSDRIVE  */ 

B=0;  C=A; 
HL=BC+DE; 
END    INDEX; 

I NDEX2 :       PROCEDURE ; 

/*   GIVEN   THE   BASE   ADDRESS   OF   AN   ADDRESS   VECTOR  AND   AN  */ 

/*    INDEX  VALUE,    THIS    PROCEDURE   CALCULATES    THE   ADDRESS  */ 

/*   OF   THE   LOW  ORDER  BYTE  OF   THE    INDEXED   ENTRY.  */ 

/*    INPUT:       A  -    INDEX  VALUE    (USUALLY  TASK)  */ 

/■*                     DE   -    BASE   ADDRESS   OF    VECTOR  */ 

/•*    OUTPUT:     BC    -    CALCULATED    OFFSET    =    2    *    INDEX   VALUE  *• 

/*                         DE   -    SAME   AS    INPUT  */ 

/*                        HL  -   CACULATED   ADDRESS   OF    INDEXED   ENTRY  */ 

/*   CALLED   BY:    SWAP,    BOOTSTRAP,    SIZE,    SELECTSDRIVE  #/ 

B=0;    C=(A=<<A); 

HL=BC+DE; 

END    INDEX2; 

I NDEX4 :       PROCEDURE ; 

/*    INPUT:       A  -    INDEX  VALUE  */ 
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/*  DE  -   BASE  ADDRESS   OF   VECTOR  */ 

/*   OUTPUT:    BC  -   CALCULATED   OFFSET  =    4   *    INDEX  VALUE  */ 

/*  DE   -   SAME  AS    INPUT  */ 

z'*  HL   -    CALCULATED    ADDRESS    OF    INDEXED    ENTRY  */ 

/*   CALLED   BY:    VALSKEY  */ 

B=0;    C=(A=<<(A=<<A))  ; 

HL=BC+DE; 

END    INDEX4; 

INDEX8:       PROCEDURE; 

/#  INPUT:       A  -    INDEX  VALUE  */ 

/*  DE    -    DASE    ADRESS    OF    VECTOR  */ 

/*  OUTPUT:     BC    -    CALCULATED    OFFSET    =    8    *    INDEX   VALUE  #/ 

/*  DE  -    SAME   AS    INPUT  */ 

/*  HL   -    CALCULATED   ADDRESS   OF    INDEXED   ENTRY  */ 

/*  CALLED   BY:    BOOTSTRAP,    VALSDRIVE,    CLEARSDM,    ATTACH,  */ 

/*  SELECT8DRIVE  */ 

/  5ps  ¥f%  *f»  5ji  .+■.  *fC  *t*  *?*  3f*  '<  ■  3n  *T*  <f*  "P  3p  5jC  w^  5f»  3fC  «fv  *P  *{>  *f«  «^*  5f£  *fs  *ft  5)s  *{<  5js>  5|C  *fC  5fs  JJC  5ft  Jft  5fC  *>f»  *Js  5fC  5j>,  *p  3fC  5|C  5fl  »,*.  5f£  5fs  5f»  5f»  *fC  *$C  5fC  *|C  / 

B=0;    C=(  A=<< ( A=<< ( A=<< A) ) )  ; 

HL=BC+DE; 

END    INDEX8; 

PUT:       PROCEDURE; 

/*   STORE   A  TWO   BYTE   ADDRESS    IN   A  SPECIFIED   VECTOR.  */ 

/*    INPUT:    DE   -    ADDRESS    TO   BE   STORED  */ 

/*  HL   -    BASE   ADDRESS   OF   VECTOR  */ 

/-*    OUTPUT:     BC    -    UNCHANGED  */ 

/*  DE   -    SAME   AS    INPUT  */ 

/*  HL   -    BASE   ADDRESS    +    1  */ 

/*   CALLED   BY:    RECOVER,     INITIALIZE  */ 

M(HL)=E;    HL=HL+1;    M(HL)=D; 
END   PUT; 

GET:       PROCEDURE; 

/*    FETCH   A   TWO    BYTE    ADDRESS    FROM   A    SPECIFIED    VECTOR.  */ 

/*    INPUT:    HL   -    BASE   ADDRESS    OF    VECTOR  */ 

/*    OUTPUT:     BC    -    ADDRESS    FETCHED  */ 

/*  DE   -    ADDRESS   FETCHED  */ 

/*  HL   -   BASE   ADDRESS   +    1  */ 

/*   CALLED   BY:    SWAP,    BOOTSTRAP,    SIZE,    SELECTSDRIVE  */ 

^  5ft  rft  5ft  5ft  5ft  5ft  «ft  rjZ  5ft  5fC  5jv  Jft  5f»  5ft  5ft  5J-,  «-,s  -ft  5f£  *|C  5ft  ?ft  r^-r  5ft  »fC  »fv  5f« 5f»  *v»  *ft  5ft  Bf*  ^^  *r*  ^^  ^^  *v*  *^  ^*  5ft  5ft  ?f» 3ft 3f»  5f* 3ft .  ft  if?  5ft  5ft  3f»  5ft  5fC5ft  f 

E=M(HL);    HL=HL+1;    D=M(HL);    BC=DE; 
END   GET; 

MOVBUF:       PROCEDURE; 

/  it  "^C  t)f  it  ^f  '  t  it  *■■'*  *t  *ir  *■"  *  Sc  *  '"*  "  J  *t  vt*  it  it  Ht  S?  Sf  s  t  jJ  tic  it  *^'  it  ^f  ^  t  *  '*  ^Jf  *^"*  it  *  ~'  ^f  ^fc  it ""''  ^Af  ^  *Js  *  ^*  *  ^  it  *v?  it  ^*T  it  ^t  iJt  it  it  isf  "A*  / 

/*    THIS    IS    A   GENERAL   PURPOSE   UTILITY  PROCEDURE   WHICH  */ 

/*   MOVES   A  SPECIFIED  NUMBER  OF   BYTES   FROM  A  SOURCE  */ 

/*   BUFFER  TO   A  DESTINATION   BUFFER.  */ 

/*    INPUT:     BC    -    NUMBER  OF    BYTES    TO    BE    MOVED  */ 

/*  DE   -    BASE   ADDRESS   OF    SOURCE   BUFFER  */ 

/*  HL   -    BASE   ADDRESS    OF    DESTINATION    BUFFER  */ 

/*   CALLED   BY:    MTSSIPL,    ABORTS IPL,    SEARCHSD I RECTORY,  */ 

/*  LOGIN,    READSFLOPPY,    WRITESFLOPPY  */ 

/  ii*  *4*  "*lf  vrT  *■£"  S^"  S^  *^  *i*  *i"  v ''  ii*  vt*  k  t-  *Jf  "i"  *+*  *^  *J^  •J'  'i*  *+"  '4*  *4*  "^*  *i*  •J'  *4f  *i*  *J*  'J'  "J*  *  J*  *»*  *  }*  *t'  *fr*  *^  vi*  vlx  si*  v>  sir  sV  si*  sl«  sir  \l/  si*  si*  s  '*  si*  •;*  sL>     / 

^  ^>  n*  *T»  *T*  *r*  "T*1  *f*  *^  *T*  *f*  ••*  *t*  *l*  ^*  ^*  *f*  *T*  *r*  •f*  *r*  *^  *o  ■!■  *i*  *T*  "f*  ^*  *r*  *t»  *r»  ^*  *^  *r»  *f*  *T»  *T*  *^  "P1  ^*  *f*  •!•  •!•  ^*  •?*  •t»  *r*  -y^  'V*  *t*  *|*  *v»  «p  t>  •!•  / 

REPEAT; 

M(HL)=<A=M(DE)  )  ; 

HL=HL+1;    DE=DE+1; 
UNTIL    (BC=BC-1;    A=0;    A::C)    ZERO    (A::B)    ZERO; 
END   MOVBUF; 

MINISDISK:       PROCEDURE; 

/*   THIS   PROCEDURE   TRANSFERS   A  SPECIFIED   512   BYTE  */ 

/*  BUFFER  BETIVEEN  MEMORY  AND  THE  MINI-DISK.  THE  DIR-  */ 
/*  ECTION  OF  THE  TRANSFER  IS  INDICATED  BY  THE  OP  CODE.*/ 
/•w    ERROR   PROCESSING    IS    LIMITED    TO    CHECKING   THE    STATUS    */ 
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/*  RETURNED  BY  THE  MINI-DISK  CONTROLLER  FOR  'NORMAL  */ 

/*  COMPLETION.'  WHEN  ANY  OTHER  STATUS  IS  RETURNED  THE  */ 

/*  ROUTINE  DISPLAYS  THE  MESSAGE  'HARDWARE  ERROR'  ON  */ 

/*  THE  TERMINAL  CURRENTLY  ALLOCATED  THE  CPU  AND  */ 

/#  ABORTS  THE  OPERATION.  */ 

/*  INPUT:  BC  -  MINI -DISK  SECTOR  NUMBER  */ 

/*         DE  -  DMA  BUFFER  BASE  ADDRESS  */ 

/*  L  -  OPERATION  CODE:  */ 

/*  1  =  READ  %/ 

/*  2  =  WRITE  */ 

/*  3  =  WRITE/VERIFY  */ 

/-*  OUTPUT:  A  -  RETURNS  00H  IF  COMPLETION  NORMAL,  *S 

/*  OTHERWISE  RETURNS  FFH  */ 

/*         BC  -  SAME  AS  INPUT  */ 

/*         DE  -  SAME  AS  INPUT  */ 

/*  CALLED  BY:  READSD I RECTORY,  RECOVER,  INITIALIZE,  #/ 

/*  WRITESREC, SWAP, BOOTSTRAP,  READSBUF,  */ 

/*  WRITESBUF  */ 

[MACRO  ABN0RMAL3C0MPLETI0N  'OFFH'] 

[MACRO  HARDWARESERROR  '3'] 

[MACRO  MTSSMSG  ' 1837H' ] 

/*  SET  DCB  CHECKSUM  IN  LOCN  4CH  */ 

M(4CH)=( A=0\B,\C,\D,\E,\L) ; 

/*  SET  SECTOR  NUMBER  IN  DISK  CONTROL  BLOCK  */ 

M(  45H)  =  (  A=B)  ;  M(  44H)  =  (  A=  C)  ; 

/*  SET  DMA  BUFFER  ADDRESS  IN  DISK  CONTROL  BLOCK  */ 

M(43H)=(A=D)  ;  M(  42H)  =  (  A=E)  ; 

/*  INITIATE  OPERATION  */ 

M(40H)  =  (  A=L)  ; 

/*  WAIT  UNTIL  OPERATION  COMPLETE  #/ 

REPEAT; 

A=M(41H)  ; 
UNTIL  (A: :G)  TZERO; 

/*  TEST  A  FOR  COMPLETION  STATUS  *• 

IF  (M(41H)  =  (A=A-D)  ZERO  RETURN;   /*  NORMAL  COMPLETION  */ 
M(41H)  =(  A=0)  ; 
E= [ HARDWARESERROR]  ; 
CALL  [MTSSMSG]  ; 
A=[ABNORMALeCOMPLETION] ; 
END  MINISDISK; 

EOF 

/*****»#*******:(:*    INITIAL   PROGRAM  LOAD   #****#*****#*#**/ 


/ne***********:*    INTERMODULE    LINKAGE    M4CR0S    sf:*::*;*:****:^****/'' 

[ INT   MB   M2B   SB   TB] 

[MB:=030OH]     [M2B:=0600H]    [SB:=1F00H]    [TB:=10O0H] 

[MACRO  MONITOR   '[HEX  M3   +    8FH]  '  ] 

[MACRO  MOVBUF    '[HEX  M2B   +    41H]'] 

[MACRO  PUT    '[HEX  M2B   +    31H]'] 

[MACRO  MINISDISK    '[HEX  M2B   +    54H]  '  ] 

[  MACRO  MTS    '  [  HEX  SB   +    0] ' ] 

[  MACRO  MTSSMSG    '  [  HEX  TB  +   837H] ' ] 

[MACRO  CLEARSSTATUSSLINE    '[HEX  TB   +   827H] ' ] 

[MACRO  TERMINALSSTATUS    '[HEX  TB    +    8D2H] * ] 

[MACRO  READSTERMINAL    '[HEX  TB   +    8DCH]  '  ] 

[MACRO  WRITESTERMINAL    '[HEX  TB   +    93CH] ' ] 

[MACRO  RECSFILE    '3E91H'] 

[M4CRO  TCT3EOE    '3EC5H'] 

[MACRO  CNFGSFILE    '3E93H'] 

[MACRO  DMTSFLAG    '3ECDH'] 

[MACRO  DMTSBOE    '3EEDH'] 

[MACRO  DMTSEOE    '3F2DH'] 

[MACRO  DMTSKEY    '3F6DH'] 

[MACRO  SYSSSTACK    'SCTAH'] 
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/*#*#*#####*#*#*   GENERAL   PURPOSE  MACROS   #***#**#*#*#**#/ 

[ INT  MEMS BASE   DIRSBASE   SSBSBASE   TOP] 

CMEM3BASE:=5O0OH]       £ SSBSBASE: =3E90H]       [TOP: =20] 

[DIRSBASE:= MEMS BASE   +    2O0H] 

[ MACRO   READ    • 1 ' ] 

[MACRO   DISKSERROR    '(A::0)     IZERO' ] 

[MACRO   DISABLESTIMER    '  OUT(  2)  =  (  A=  1)  '  ] 

[MACRO    CLEARSCSST3INT    ' OUT( 85H) = ( A= 10H) ' ] 

[  MACRO   CLEARSPRNTS INT    ' A= IN( SAH) ' ] 

[M^CRO   RESETSTIMER    '  OUT(  2)  =  (  A=0)  '  ] 

/##**##:(::;:******#*    MODULE    DECLARATIONS   **«****:!r*;{:*#:fc*#*#ac/ 

DECLARE    I    BYTE; 
DECLARE   M4X(2)    BYTE; 

/*   ADDRESS   OF   LAST  ENTRY  +    1    IN   DIRECTORY    IMAGE   */ 
DECLARE   RECSNAME(9)    BYTE    INITIAL   (  ' . MTSRCVRS' ) ; 

/*#*-.&#**#***«#******    PROCEDURES    *********sc*s»e*af:sicsi«<es|c*stMinfe9»8/ 

ABORTSIPL:       PROCEDURE( MSG) ; 

/*  WHENEVER  A  CONDITION  OCCURS  DURINC  THE  I PL  PROCESS  */ 
/*  WHICH  PREVENTS  NORMAL  COMPLETION  OF  THE  IPL  THIS  */ 
/*   PROCEDURE    IS   CALLED   TO   TERMINATE   EXECUTION   AND  #/ 

/*    DISPLAY   AN   ERROR  MESSAGE   AT   TERMINAL   0.  */ 

/*  INPUT:  MSG  -  BASE  ADDRESS  OF  ERROR  MESSAGE  */ 

/*  TERMINATED   BY    'S'  */ 

/*    CALLED   BY:    READ3D I  RECTORY,     INITIALIZE,    RECOVER,  */ 

/#:£*:£  :!:***:fc^o£  :*;#*&:;:*:(;:;:«:£*:£*#** 

DECLARE   ABORTS MSG  DATA    (  ' IPL   ABORTED   -    ' )  ; 

/*   DISPLAY   'IPL   ABORTED'    AT  TERMINAL   0   */ 

BC=14;    DE=.AEORTSMSG;    HL=0700H; 

CALL    [MOVBUF]  ; 

HL=MSG;     A='S'; 

DO    C=G    BY   C=C+1    WHILE    <A::M(HL>>     TZERO; 
HL=HL+1;       /*    COUNT  CHARS    IN   MSG   */ 

END; 

B=0;    DE=(HL=MSG);    HL=070EH; 

CALL   [MOVBUF];       /*   DISPLAY  MSG   AT  TERMINAL   0   */ 

HALT; 

END   ABORTSIPL; 

READSD I RECTORY:       PROCEDURE; 

/*  DURING  THE  INITIALIZATION  PROCESS  IT  IS  NECESSARY  */ 
/*  TO  DETERMINE  THE  SECTOR  NUMBERS  OF  SEVERAL  SYSTEM  */ 
/*  FILES  WHICH  RESIDE  ON  THE  MINI-DISK  IN  SYCOR  FORMAT.*/ 
/*  MULTIPLE  DIRECTORY  SEARCHES  COULD  LEAD  TO  REPEATEDLY*/ 
/*   READING   THE   SAME   BLOCK  OF    MINI-DISK  SECTORS.    TO  */ 

/*  ELIMINATE  MOST  OF  THESE  UNNECESSARY  READ  OPERATIONS  */ 
/#   THIS   PROCEDURE   READS   THE   ENTIRE   SYCOR  DIRECTORY  */ 

/*  INTO  MEMORY  AT  ONE  TIME,  THUS  REDUCING  THE  OVERHEAD  */ 
/*    INVOLVED    IN    MULTIPLE   SEARCHES.  */ 

/#   CALLED   BY:    MTSSIPL  */ 

/  Jfs  ?P  'p  "t*  3P3F  «p  »{*  SP  *f**l^  t»  »t»  *S*T*  *f  »r*  <f»  k>»t»  5p  *>*'?*  *T»  'K  5p  5f»5f»3p  'S  'f*  .,s  *JC*fC  JjC  .■;-.  ^fC^f*  Jfl  •/**,*  Jji  »r»  #|»  •pJjC  «■(»  rf-»^fv  Jf.5[C  Jf»2j>  »?£  Jfc  / 

[ INT  SYCORSDIRSBASE]       /*   SYCOR  DIRECTORY  BASE   */ 

[SYCORSDIRSBASE:=20H]    /*   SECTOR  NUMBER  */ 

DECLARE    MSG   DATA    ('CANNOT    READ    D I RECTORYS ' ) ; 

/*    SET   UP    REGISTERS   FOR  DISK  READ   */ 

BC=[HEX   SYCORSDIRSBASE]; 

DE=[HEX  DIRSBASE]; 

/*    READ   NUMBER  OF   SECTORS    INDICATED   */ 

/*    IN   DIRECTORY  HEADER  RECORD  */ 

REPEAT; 

L=[READ];    CALL    [MINISDISId; 

IF    [DISKSERROR]    CALL   ABORTS  I PL (. MSG) ; 

DE=(HL=200H+DE) ;    BC=BC+1; 
UNTIL    (  A=M(  [HEX   DIRSBASE+0AH3  )  ;     A::C)     CY; 
/*   CALCULATE    ADDRESS    OF    LAST   ENTRY  +    1     IN    IMAGE   */ 
B=  [  HEX  SYCORSD I RSBASE- 1 ] ; 
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A=A-B;   /*  A  =  NR  SECTORS  IN  DIRECTORY  */ 

D=(A=<<A)  ; 

E=0;   /*  DE  =  NR  SECTORS  *  512  */ 

MAX=(HL=[HEX  DIRSBASE+13+DE) ; 

END  READSD I RECTORY; 

SEARCHED I RECTORY:   PROCEDURE; 

/*  GIVEN  THE  BASE  ADDRESS  OF  A  VECTOR  CONTAINING  THE  */ 

/*  NAME  OF  A  FILE  IN  SYCOR  FORMAT,  THIS  ROUTINE  WILL  */ 

/*  SEARCH  THE  DIRECTORY  IMAGE  READ  INTO  MEMORY  BY  */ 

/%  READSD I RECTORY.  IF  THE  FILE  ENTRY  IS  FOUND,  THE  */ 

/*  BOE  AND  EOE  VALUES  ARE  RETURNED.  */ 

/"*  INPUT:  DE  -  BASE  ADDRESS  OF  FILENAME  VECTOR  */ 

/#  ASSUMED  TO  BE  8  BYTES  LONG  */ 

/*  OUTPUT:  BC  -  BOE  OR  FFFFH  IF  FILE  NOT  FOUND  */ 

/*  DE  -  EOE  OR  FFFFH  IF  FILE  NOT  FOUND  */ 

/*  CALLED  BY:  INITIALIZE,  RECOVER  */ 

DECLARE  LOOP  LABEL; 

/*  MOVE  FILENAME  TO  LAST  ENTRY  +  1  */ 
BC=8;  HL=MAX;  CALL  [MOVBUF]; 

DE=[REX  DIRSBASE+41H] ;  /*  ADDRESS  OF  FIRST  ENTRY  */ 
LOOP:   /*  ADVANCE  TO  NEXT  ENTRY  */ 
STACK=DE;  HL=MAX;  B=8; 
REPEAT;   /*  COMPARE  CHAR  BY  CHAR  */ 
IF  (A=M(DE);  A::M(HL))  ZERO 
\  <  IF  (A::0)  ZERO   (  A=M(  HL) -20H)  ZERO 
THEN  CY=  1  ELSE  CY=G)  CY 
THEN   /*  CHAR  MATCH  */ 
DO; 

DE=DE+1;  HL=HL+1; 
END 
ELSE   /*  NON-MATCH  */ 
DO;  DE= STACK; 
DE=(HL=40H+DE)  ; 
GOTO  LOOP; 
END; 
UNTIL  (B=B-1)  ZERO; 
SP=(HL=2+SP) ;  /*  CLEAR  STACK  *• 

/*  FALLING  THRU  LOOP  MEANS  NAMES  MATCH,        */ 
/*  MUST  TEST  FOR  SUCCESS  OR  FAILURE  OF  SEARCH  */ 
IF  (A=MAX(1);  A::D)  CY  /*  X::Y=CY  =>  X<  Y  */ 
\(  IF  ZERO   (A=MAX(8);  A::E)  CY  THEN  CY=  1  ELSE  CY=0) 
CY  THEN 

DO;   /*  SEARCH  FAILED  */ 
BC=OFFFFH;  DE=BC; 
END 
ELSE  DO:   /*  SEARCH  SUCCESSFUL  */ 
HL=3+DE; 

C=M(HL);  HL=HL+1: 
B=M(HL);  HL=HL+1 
E=M(HL);  HL=HL+1 
D=M(HL)  ; 
END; 
END  SEARCHED I RECTORY; 

RECOVER :   PROCEDURE ; 

/■*  MTS  HAS  BEEN  DESIGNED  SO  THAT  THE  SYSTEM  STATE  AT  *• 

/*  ANY  INSTANT  IS  DEFINED  BY  A  COMPACT,  CONTIGUOUS  */ 

/*  GROUP  OF  BYTES  KNOWN  AS  THE  SYSTEM  STATE  BLOCK.  */ 

/*  EACH  TIME  THAT  SWAPPING  OCCURS  THE  SSB  IS  WRITTEN  #/ 

/*  TO  THE  MINI-DISK  FILE  . MTSRCVR.  IF  THE  TASK  JUST  */ 

/*  SWAPPED  IN  CAUSES  A  SYSTEM  CRASH,  RECOVERY  IS  */ 

/*  ACCOMPLISHED  BY  REBOOTING  MTS  AND  ANSWERING  ' Y'  TO  */ 

/-*  THE  RECOVERY  O.UERY.  MTS  WILL  READ  .MTSRCVR  BACK  */ 

/*  INTO  THE  SSB,  DELETE  THE  OFFENDING  TASK,  AND  */ 

/*  CONTINUE  WITH  THE  NEXT  READY  TASK.  */ 

/*  NOTE:  THIS  PROCEDURE  USES  THE  FACT  THAT  THE  BOE  */ 

/*        AND  EOE  VALUES  RETURNED  BY  SEARCHSD I RECTORY  */ 

/*        ARE  EQUAL  FOR  A  SINGLE- SECTOR  FILE.  */ 
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•*  CALLED  BY:  MTSSIPL  */- 

[ MACRO  BUMP  ' -2 ' ] 

[MACRO  OUTSOFSBOUNDS  '7'] 

/*  FIND  MINI-DISK  SECTOR  ADDRESS  OF  . MTSRCVR  */ 

DE=.REC3NAME; 

CALL  SEARCESD I RECTORY; 

IF  (A=B;  A::OFFH)  ZERO  CALL  ABORTS  I PL(  . RECSNAME) ; 

/■■*  READ  .MTSRCVR  INTO  SSB  */ 

HL=[RECSFILE] ;  CALL  [PUT]; 

DE= [ SSBSBASE3 ; 

L=[READ];  CALL  [MINISDISK]; 

IF  [DISKSERROR]  CALL  ABORTS  I PL( . RECSNAME) ; 

/*  DELETE  TASK  CAUSING  CRASH  *• 

C=[BUMP1 ; 

CALL  [MTS]; 

E=[ OUTSOFSBOUNDS] ; 

CALL  [ MTSSMSG] ; 

END  RECOVER; 

INITIALIZE:   PROCEDURE; 

/*  THE  SYSTEM  STATE  BLOCK  CONSISTS  OF  THREE  SETS  OF  */ 
/*  VARIABLES:  SYSTEM  CONTROL,  TASK  CONTROL  TABLE,  AND  */ 
/*  THE  DISK  MAP  TABLE.  THE  OBJECT  MODULE  GENERATED  BY  */ 
/*  THE  ML80  COMPILER  CONTAINS  INITIAL  VALUES  FOR  */ 
/*  SYSTEM  CONTROL  VARIABLES  AND  MOST  OF  THE  TCT.  IN  */ 
/*  ORDER  TO  INITIALIZE  THE  REST  OF  THE  TCT  IT  IS  */ 
/*  NECESSARY  TO  SEARCH  THE  SYCOR  DIRECTORY  IMAGE  */ 
/%  COPIED  INTO  MEMORY  BY  READSD I  RECTORY  FOR  BOE  AND  *• 
/*  EOE  VALUES  FOR  THE  RECOVERY  FILE  AND  ALL  FOUR  SWAP  */ 
/*  FILES.  TO  INITIALIZE  THE  DMT  THE  VIRTUAL  DISK  */ 
/*  CONFIGURATION  FILE,  .MTSCNFG,  MUST  BE  READ  INTO  */ 
/*  MEMORY  AND  EOE  AND  EOE  VALUES  FOR  THE  VIRTUAL  DISK  */ 
SX  FILES  EXTRACTED  FB.OM  THE  SYCOR  DIRECTORY  IMAGE.  */ 
/*  THE  PROTECTION  ATTRIBUTES  FOR  EACH  VIRTUAL  DISK  */ 
/*  ARE  ALSO  COPIED  INTO  THE  DMT  FROM  .MTSCNFG.  */ 
/*  NOTE:  THIS  PROCEDURE  USES  THE  FACT  THAT  THE  BOE  */ 
/*  AND  EOE  VALUES  RETURNED  BY  SEARCHSD I RECTORY  */ 
/#        ARE  EQUAL  FOR  A  SINGLE-SECTOR  FILE.  */ 

•"*  CALLED  3Y:  MTSSIPL  *^ 

DECLARE  ENTRYSBASE(2)  BYTE; 

DECLARE  CNFGSNAME(9)  BYTE  INITIAL  ( ' . MTSCNFGS ' ) ; 

DECLARE  SWAPSNAMEC9)  BYTE  INITIAL  ( ' . MTSSWPOS ' ) ; 

DECLARE  SYSDISK(9)  BYTE  INITIAL  ('SYS  DISKS'); 

/*  SET  UP  RECOVERY  FILE  */ 

DE=. RECSNAME;  CALL  SEARCHSD I RECTORY; 

IF  (A=B;  A::0FFH)  ZERO  CALL  ABORTS  I PL(  . RECSNAME)  ; 

HL=[RECSFILE3 ;  CALL  [PUT]; 

/*  SET  UP  TASK  CONTROL  BLOCK  IN  SSB  */ 

I=(A=4);  STACK=(HL=[TCTSEOE])  ; 

REPEAT; 

DE=.SWAPSNAME;  CALL  SEARCHSD I RECTORY; 

IF  (A=B;  A::0FFH)  ZERO 

CALL  ABORTS  I PL(  . SVAPSNAME)  ; 

/%  CHECK  THAT  SWAP  FILE  AT  LEAST  16K  */ 

L=(A=!C,  +  1);  H=(A=  !B,++0)  ; 

HL=HL+DE; 

IF  (A=L;  A::31)  CY  CALL  ABORTS  I PL(  . SWAPSNAME) ; 

HL= STACK;  CALL  [PUT]; 

DE=BC;  BC=-9; 

RL=HL+BC;  CALL  [PUT]; 

BC=  9 ;  STACK= ( HL=  HL+BC )  ; 

SWAPSNAME(  7)  =  (  A=SWAPSNAME( 7)  +  1 ) ; 
UNTIL  (I  =  (A=I-1))  ZERO; 
SP=(HL=2+SP) ;   /*  CLEAR  STACK  */ 
•**  SET  UP  DISK  MAP  TABLE  IN  SSB  */ 
DE= . CNFGSNAME ;  CALL  SEARCHSD  I  RECTORY; 
IF  (A=B;  A::OFFH)  ZERO  CALL  ABORTS  I PL(  . CNFGSNAME) ; 
HL=[CNFGSFILE] ;  CALL  [PUT]; 
/*  READ  CONFIGURATION  FILE  INTO  MEMORY  */ 
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DE=IMEMSBASE]  ;  L=[READ1;  CALL  [  MINISDISKI ; 
IF  [DISKSERROR]   CALL  ABORTS  I PL< . CNFGSNAME) ; 
I=(A=0);  ENTRYSBASE=  (  HL=  (  DE= t HEX  MEM3BASE  +  2]))? 
REPEAT;   /*  STEP  THRU  CONFIGURATION  FILE  */ 
CALL  SEARCHED  I  RECTORY; 
IF  (A=B;  A::OFFH)  'ZERO  THEN 

DO;   /*  VIRTUAL  DISK  ( I)  EXISTS  */ 
STACK=BC;  B=0;  C=(A=<<I); 
HL=[DMTSEOE]+BC;  CALL  [PUT]; 
DE=STACK;  HL= [ DMTSBOEI+BC;  CALL  [PUT!; 
BC=  6 ;  DE=  (  HL=  ENTRYSB ASE+  BC )  ; 
B=0;  C=( A=<<( A=<< I) ) ; 
HL=[DMTSKEY]+BC; 

DO  B=G  BY  B=B+1  WHILE  (A=B-4)  tZERO; 
M(HL)  =  (A=M(DE>)  ; 
DE=DE+1;  HL=HL+1; 
END; 

B=0;  C=(A=I); 
HL= I DMTSFLAGI +BC ; 
IF  <A=M(DE);  A:;<B='R')>  ZERO  THEN 

M(HL)=0DH 
ELSE  DO; 

IF  (A::(B='P'>)  ZERO  THEN  M(HL)=05H 
ELSE  M(HL)=01H; 
END; 
END; 
DE= ( HL=  ENTRYGBASE+ ( BC= 13)); 
ENTRYSBASE=HL; 
UNTIL  (I=(A=I+1);  A:: 32)  ZERO; 
/*  CHECK  THAT  DISK  0  EXISTS  */ 
HL=[DMTSFLAG] ; 

IF  (A=M(HL)   01)  ZERO  CALL  ABORTSIPL(  .  SYSDISK)  ; 
END  INITIALIZE; 

MTSSIPL: 

/*  THIS  ROUTINE  IS  THE  INITIAL  ENTRY  POINT  INTO  MTS.  */ 

/%   THE  SYCOR  440  LOADER  TRANSFERS  CONTROL  HERE  AFTER  */ 

/*  THE  SYSTEM  OBJECT   NODULE  HAS  BEEN  LOADED.  DURING  */ 

/"*     I  PL  ;\LL  PERIPHERAL  DEVICES  ARE  RESET,  THEN  KTS  */' 

/*  READS  THE  SYCOR  DIRECTORY  INTO  MEMORY,  AND  ASKS  */ 

/*  THE  OPERATOR  AT  TERMINAL  0  WHETHER  RECOVERY  IS  */ 

/*  REQUIRED.  IF  THE  ANSWER  IS  »Y«  THEN  THE  PROCEDURE  */ 

/*  RECOVER  IS  CALLED  TO  READ  THE  FILE  .MTSRCVR  INTO  */ 

/*  THE  SYSTEM  STATE  BLOCK.  OTHERWISE  THE  PROCEDURE  */ 

S*    INITIALIZE  IS  CALLED  TO  BUILD  AN  SSB  FROM  INFOR-  */• 

/*  MAT I ON  CONTAINED  IN  THE  SYCOR  DIRECTORY  IMAGE  AND  */ 

/*   THE  FILE  .MTSCNFG.  ONCE  IPL  IS  COMPLETE  CONTROL  IS  */ 

/*  TRANSFERRED  TO  THE  PROCESSOR  MANAGEMENT  SUBMODULE  */ 

/*  WHICH  WILL  CONTROL  ALL  SUBSEQUENT  PROCESSING.  *• 

/*  CALLED  BY:  SYCOR  SYSTEM  LOADER  */ 

DECLARE  (WAIT,  TEST)  LABEL; 

DECLARE  IPL$MSG( 15)  BYTE  INITIAL  ('RECOVERY?  (  Y/N)  ' )  ; 

/*  SET  STACK  POINTER  */ 

DE=[T0P1 ; 

SP= ( HL=  [  SYS0STACK3  +  DE) ; 

/*  CLEAR  PERIPHERAL  INTERRUPTS  */ 

[DISABLESTIMER] ; 

[CLEARSCSSTSINT] ; 

[CLEARSPRNT8INT] ; 

/*  CLEAR  STATUS  LINE  ON  ALL  TERMINALS  *• 

DO  I=(A=0)  BY  I=(A=I+1)  WHILE  ( A= I ;  A::4)  IZERO; 

CALL  CCLEARSSTATUSSLINE] ; 
END; 

/*  READ  SYCOR  DIRECTORY  INTO  MEMORY  *• 
CALL  READSD I RECTORY; 

/*  DISPLAY  IPLSMSG  AT  TERMINAL  0  */ 
BC=15;  DE=.IPLSMSG;  HL=0700H; 
CALL  [ M0VBUF3 ; 

/*  ENABLE  INTERRUPTS  SO  TERMINAL  MODULE  MAY  */ 
/*  BE  USED  TO  PROCESS  REPLY  TO  IPL3MSG       */ 
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ENABLE; 

[RESETSTIMER]  ; 

/*  PROCESS  OPERATOR'S  REPLY  */ 

WAIT:  REPEAT; 

CALL  [TERMINALSSTATUS] ; 
UNTIL  (A: :0)  !ZERO; 
CALL  C  READSTERMINAL3 ; 
I  =  A; 

IF  (A::0DH)  ZERO  GOTO  TEST; 
REPEAT; 

CALL  [READSTERMINALJ ; 
UNTIL  (A::ODH)  ZERO; 
TEST: 

IF  (A=I;  A::(B='Y*  ))  ZERO 

\  (A:  :(B=79H))  ZERO 
THEN  CALL  RECOVER 
ELSE  DO; 

IF  (A: :(B='N'))  TZERO 

(A::(B=6EH))  'ZERO 
THEN 

BO;  E='?'; 

CALL  [  WRITESTERMINAL]  ; 
GOTO  WAIT; 
END 
ELSE 

DO; 

CALL    INITIALIZE; 
A=0;    CALL    [ CLEARSSTATUSSLINE1 
END; 
END; 
GOTO    [MONITOR! ; 
/*   END   NTS3IPL   */ 


EOF 
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/  «£»  ■si'  *>  -i*  vi*  »*»«.[-  -m  ■vi'-^v  -f  vj*  vy  *>  *.v  »j<  *>,  •>•  v*^*  ■•'  *i*  *>»  >.v  i>'J'«i»*>'>«}'*i» »+»  »>•  ■*■*  •.(-  -.*•  ■>>  ~>  «a»  ->  «.i»  ■->  vj^*i*  %a«  »j*  ->»>r;'»;'^4>«>*v  y 
/  *(S  -T-  «^  ^  ^  «^  *^  *^  *V*  *^  *fr  ^*  *^  •n*  *f+  ^*  »f*  ^*  ^1  ^»  "*>  H*  *^  '**  "V*  *T+  "V»  *T*  ^*  *^  *T*  *I>  «Y*  *f*  *T»  'I*  ^  ^  ^  ^  ^  ^  *T*  *^  ^»  ^  *^  ^  ^»*o  -f*  ^  ^  ^  f 

/*  SERVICE   MODULE  */ 

/*  */ 

/■*    THIS    MODULE            PROVIDES    THE    INTERFACE    BETWEEN  THE      */ 

/*    USER  AND   ALL   SYSTEM  SERVICES.       THESE   SERVICES  FALL   */ 

/*    GENERALLY    INTO   TWO   CATEGORIES:  */ 

/*      (1)    SYSTEM  CALLS   -   THOSE   FUNCTIONS   REQUIRED   TO  */ 

/*  ESTABLISH  THE   DESIRED   VIRTUAL   MACHINE  */ 

/*  ENVIRONMENT.  */ 

z'*  */ 

/*  (2)  SERVICE  CALLS  -  THOSE  FUNCTIONS  REQUIRED  TO  */ 
/*  ACCESS    THE   VIRTUAL   DEVICES   PROVIDED   BY  THE  */ 

/*  VIRTUAL   MACHINE   ENVIRONMENT.  */ 

/*  */ 

/*  SYNTACTICALLY  THE  TWO  TYPES  OF  PROCEDURE  CALL  ARE  */ 
/-*    IDENTICAL,     I.E.  *s 

/*  VALUE    =    MTS(FID,PARM) .  */ 

/#  EACH  CALL  TAKES  TWO  ARGUMENTS,  FID  IN  REGISTER  C  */ 
/%    AND   PARM    IN   REGISTERS    DE;    AND   RETURNS    A   VALUE  */ 

/*  IN  THE  A  REGISTER.  THE  FORM  OF  THE  ARGUMENTS  AND  */ 
/*   THE   SIDE   EFFECTS   ASSOCIATED   WITH  EACH  DIFFERENT  */ 

/*  FUNCTION  ARE  DISCUSSED  IN  MORE  DETAIL  IN  THE  MTS  */ 
/"*  USER'S  MANUAL.  NOTE  HOWEVER  THAT  THE  ARGUMENT  REG-  */ 
/*  ISTER  ASSIGNMENTS  CONFORM  TO  THE  PL/M  CONVENTION  */ 
/*  FOR  PASSING  PARAMETERS.  THE  FOLLOWING  TABLE  SUM-  */ 
/*   MARIZES   THE   ARGUMENT  OPTIONS   AND   CORRESPONDING  */ 

/*   RETURNED   VALUES.  */ 

/*  */ 

/*         FID  NAME  PARM  VALUE  */ 

/■*         */ 

/*         SYSTEM   CALLS */ 

/*  0         ATTACH  LIST  ERROR  */ 

/*  1         D I SPLAYS MSG  ERROR  NONE  */ 

•*  2         LOGIN  LIST  ERROR  */ 

/*  3         PROTECT  LIST  ERROR  */ 

/■»  4  QUIT  NONE  NONE  */ 

/*  5         RESTRICT  LIST  ERROR  */ 

/*  6         SIZE  SIZE  ERROR  */ 

/*  7         UNPROTECT  LIST  ERROR  */ 

/*        SERVICE   CALLS */ 

/*  8        TERMINAL8STATUS        NONE  TRUE/FALSE  */ 

/*  9         READSTERMINAL  NONE  CHARACTER  */ 

SX  10         WRITESTERMINAL  CHARACTER         NONE  */ 

/*  11         WRITE8PRINTER  CHARACTER         ERROR  */ 

/*         12         SELECTSDRIVE  DRIVE   NR  ERROR  */ 

/*  13         SETSDMA  DMA   ADDRESS   ERROR  */ 

/*  14         SETSTRACK  TRACK   NR  NONE  */ 

/*         15         SETSSECTOR  SECTOR   NR         ERROR  */ 

/*         16         READSFLOPPY  NONE  ERROR  */ 

/*  17         WRITESFLOPPY  NONE  ERROR  */ 

/*  #/ 

/*  IN  THIS  TABLE  THE  ENTRY  'LIST'  UNDER  PARM  INDICATES*/ 
/*  THAT  THE  ACTUAL  ARGUMENT  IS  THE  ADDRESS  OF  A  LIST  */ 
/*  OF  REQUIRED  PARAMETERS.  WHEN  'NONE'  APPEARS  UNDER  */ 
/*  THE  SAME  HEADING,  IT  MEANS  THAT  THE  PARM  ARGUMENT  */ 
/*  IS  NOT  REQUIRED.  IF  'NONE*  APPEAPS  UNDER  VALUE  THE  *• 
/*    ERROR  CODE   RETURNED    IS   ALWAYS    ZERO.    THE   ENTRY  */ 

y*  'ERROR'  INDICATES  THAT  AN  ERROR  CODE  IS  RETURNED.  */ 
/*   THESE   CODES   ARE   DEFINED  AS   FOLLOWS:  */ 

/#  an/ 

%/ 
*/ 
*/ 
*■/ 
%/ 
*/ 
*/ 
*/ 
*/ 
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/* 

CODE 

ERROR 

/* 



/■* 

0 

OPERATION    SUCCESSFUL 

/* 

1 

INVALID    COMMAND 

/* 

2 

DISK  NOT   AVAILABLE 

/# 

3 

DISK    IN  USE 

/* 

4 

DISK  NUMBER   ERROR 

/* 

5 

KEY  ERROR 

/* 

6 

DRIVE   LETTER  ERROR 

/■■» 

7 

OUT   OF    BOUNDS 

/*  8                          HARDWARE   ERROR  */ 

/*  9                          PROTECTION   ERROR  */ 

/*  10                          DRIVE   NOT  AVAILABLE  */ 

/*  */ 

/*  THE    SERVICE    MODULE    IS    DIVIDED    INTO    THREE    BASIC  */ 

/*  SUBMODULES:  */ 

/■*  */ 

/*  (1)    USER    INTERFACE  */ 

/*  THIS   SUBMODULE   CONTAINS   THE   ENTRY  POINT    INTO  */ 

/*  THE   SERVICE    MODULE   FROM  MCP    AND   USER  PRO-  */ 

/*  GRAMS.     IT    IS    HERE   THAT  THE   SERVICE   REQUEST  */ 

/*  IS    INTERPRETED    AND    THE   APPROPRIATE   SERVICE  *• 

/*  ROUTINE   CALLED   FOR  EXECUTION.  */ 

/%  */ 

/*  (2)    SYSTEM  CALLS  */ 

/*  THIS   SUBMODULE   CONTAINS   THE   SERVICE   ROUTINES  */ 

/*  AND  SUPPORTING   PROCEDURES   WHICH  CREATE  OR  */ 

/*  MODIFY  THE   USER'S   VIRTUAL   ENVIRONMENT.  */ 

,"*  THESE    ROUTINES    ARE    INVOKED    BY  MCP    IN    RESPONSE  */ 

/*  TO    SYSTEM   COMMANDS    ENTERED    AT   A   TERMINAL.  */ 

/*  THEY  MAY  ALSO   BE   ACCESSED   BY  USER  PROGRAMS  */ 

/%  DIRECTLY  THROUGH  THE    USER    INTERFACE   SUBMODULE.*/ 

/*  */ 

/*  (3)    SERVICE   CALLS  */ 

/•*  THIS    SUBMODULE    CONTAINS    SERVICE    ROUTINES    AND  */- 

/*  SUPPORTING   PROCEDURES    WHICH    ALLOW   A    USER  */ 

/*  PROGRAM  TO   ACCESS    A   VIRTUAL   TERMINAL   OR  */ 

/*  VIRTUAL   FLOPPY  DISK.  */ 

/*  */ 


/sK*^*************-***    USER    INTERFACE  #*#*#**##*#*******#/' 


/*#****#:•:*:(:*:!-.*    INTERMODULE   LINKAGE   MACROS    ************/ 

[  INT  ME   TB   M2B]     [M2B:  =O60OH]    CMB:=0300H]    [TB:=10CGH] 

C INT  S2B   S3BI       [S2B:=2200H3       [S3B:=2600H3 

C  M4CRO   MONITOR    ' [ HEX  MB   +8FH] ' J 

[MACRO    INDEX    '[HEX   M2B   +    3H3  '  ] 

[MACRO   ATTACH    '[HEX  S2B   +    14 AH] ' ] 

[MACRO   LOGIN    '[HEX  S2B   +    208H3  '  ] 

[  MACRO   PROTECT    '  [  HEX  S2B    +    25CH] ' ] 

[MACRO   QUIT    '[HEX  S2B   +    261H]'] 

[MACRO   BUMP    '[HEX  S2B   +    293HJ  '  1 

[MACRO   RESTRICT    '[HEX  S2B   +    2C2H1  '  ] 

[MACRO   SIZE    '[REX  S2B   +    2C7H3 ' ] 

[MACRO   UNPROTECT    '[HEX  S2B  +   31FH1'] 

[MACRO   WRITESPRINTER    '[HEX  S3B   +   0EDH] * ] 

[MACRO    SELECTSDRIVE    '[HEX   S3B    +    0F2H3 ' 3 

[MACRO    SETSDMA    '[HEX   S3B    +     15FH3  '  3 

[MACRO   SETSTRACK    '[HEX  S3B   +    17CHI ' I 

[MACRO    SETSSECTOR    '[HEX   S3B    +     186H] ' ] 

[MACRO   READSFLOPPY    '[HEX  S3B   +    1A0H]'] 

[MACRO   WRITESFLOPPY    '[HEX  S3B   +    1B4H] ' ] 

[ MACRO   MTSSMSG    ' C HEX  TB   +    837H] ' ] 

[MACRO   TERMINALSSTATUS    '[HEX  TB   +   8D2H] ' ] 

[MACRO   READSTERMINAL    '[HEX  TB   +    8DCHI ' 3 

[MACRO    WRITESTERMINAL    '[HEX   TB    +    93CH3 • 3 

/***********##**    GENERAL   PURPOSE   MACROS    #****##***#****/ 

[ INT  TOP]   [TOP: =20] 

[MACRO  INPUT3WAITING  "OFFH'3 

/#:)::):*##**##***##.•(;*#*#  DECLARAT I ONS  *#***********5lt**5ln|t**/ 

DECLARE  (MTSSEXTERNAL,  MTSS INTERNAL,  EXIT, 
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NTS , TERMSBLOCK)  LABEL; 
DECLAflE  SAVE  DATA  (0,0,0); 

/##**#*#>;:**#:$:#*:;:*###«  ENTRY  POINT  #****##**#*#*•.*:#****#*/ 

INTERNALSMTS:  /*  INTERNAL  ENTRY  POINT  INTO  SERVICE  */ 
/*  MODULE,  I.E.  ENTRY  POINT  FROM  */ 
/*  OTHER  MTS  ROUTINES  #/ 

SAVE(2)=(A=L0CK) ;   /#  SAVE  LOCK  VALUE  */ 
PARM=(HL=DE) ;   /*  SAVE  PARM  LIST  ADDRESS  */ 
SAVE=(HL=0+SP) ;     /"*    SAVE  USER  SP  */ 
SP= ( HL= . SVCSSTACK(  [  TOP] ) ) ; 
IF  (A=<<C)  ICY  GOTO  MTS; 

A=(A=!C)+I;   /*  CONVERT  FID  TO  POSITIVE  NR  */ 
IF  (A: :3)  ICY  THEN 

/#  INVALID  COMMAND  -  ERROR  1  */ 
DO ;  ERROR=  (  A= 1 ) ;  GOTO  EXIT;  END ; 
H=0;  L=A; 
DO  CASE  HL; 

/*   0  */   DO;  NOP;  END; 
/-*  -l  */-   DO;  CALL  C  READ3TERMINAL3  ; 
E3R0R=A; 
END; 
/%    -2  */   CALL  [BUMP1; 
END;  /*  CASE  */ 
GOTO  EXIT; 

10OH:  /*   ADJUST  EXTERNAL  ENTRY  POINT  LOCATION  */ 
EXTERNALSMTS:   /*  EXTERNAL  ENTRY  POINT  INTO  SERVICE  */ 
/*    MODULE,  I.E.  ENTRY  POINT  FROM      */ 
S*    USER  PROGRAMS  */ 

DISABLE; 

SAVE(2)=(A=L0CX   OFEH) ;  /*   SAVE  LOCK  VALUE  *• 

LOCK=(A=A  \  01);   /*  LOCK  OUT  SWAPPING  %/ 

ENABLE; 

PARM=(BL=DE) ;   •*  SAVE  PARM  LIST  ADDRESS  */ 

SAVE=(HL=0+SP) ;    /*  SAVE  USER  SP  */ 

SP= (  RL= . SVCSSTACKC  [  TOP] ) )  ; 

MTS:   /*  SYSTEM  AND  SERVICE  ROUTINES  */ 
IF  (A=C;  A: : 18)  !CY  THEN 

/*  INVALID  COMMAND  -  ERROR  1  */ 
DO;  ERR0R=(A=1);  GOTO  EXIT;  END; 


ERROR=(  A=0)  ; 

/*  INITIALIZE  RETURNED  ERROR  CODE  * 

H=0 

;  L= 

:C; 

DO 

CASE  HL; 

/Xc***:,^**^j 

SYSTEM  CALLS  ********::;#****:*:*/ 

/* 

0 

*/ 

CALL  [ ATTACH] ; 

/* 

1 

%/ 

CALL  C  MTSSMSG]  ; 

/* 

2 

#/ 

CALL  [LOGIN] ; 

/* 

3 

■*/ 

CALL  [ PROTECT] ; 

/* 

4 

*/ 

CALL  [QUIT] : 

/* 

5 

*/ 

CALL  [RESTRICT]  ; 

/* 

6 

*/ 

CALL  [SIZE] ; 

/* 

7 

*/ 

CALL  [ UNPROTECT] ; 

/#**#**** 

SERVICE  CALLS  *##***##*#*****/ 

/* 

8 

*/ 

DO;  CALL  [TERMINALSSTATUS]; 

ERROR=A; 
END; 

/* 

9 

xs 

DO;   CALL  [TERMINALSSTATUS]; 

IF  (A: :[ INPUTSWAITING] )  ZERO  THEN 
DO;  CALL  [ READSTERMINAL] ; 

ERROR=A; 
END 
ELSE  GOTO  TERMSBLOCK; 
END; 

/% 

10 

%/ 

CALL  [WRITESTERMINAL] ; 

/■*■ 

11 

*/ 

CALL  [VRITESPRINTER] ; 

/"* 

12 

*/ 

CALL  [SELECTJ5DRIVE]  ; 

/% 

13 

*/ 

CALL  [  SETSDM4]  ; 

/* 

14 

#/ 

CALL  [  SETSTRACK] ; 

/% 

15 

*/ 

CALL  [  SET3SECT0R]  ; 
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/*    16    */      CALL   [ READSFL0PPY1 ; 
/*    17   */      CALL   [WRITESFLOPPY]  ; 
END;    /*   CASE   */ 

EXIT:       /*    COMMON    EXIT   POINT   FOR    INTERNAL    AND    EXTERNAL    */ 
SP=(HL=SAVE) ;       /*    RESTORE    USER  SP    *• 
DISABLE; 

LOCK=(  A=SAVE(2))  ;       /*   RESTORE   LOCK  VALUE   */ 
A= ERROR; 
ENABLE; 
RETURN; 
/*   END   MTS   */ 

TERM8BL0CK: 

/*   THIS   ROUTINE    IS   CALLED   WHEN   THE   TASK  CURRENTLY  */ 

/"*  ALLOCATED  THE  CPU  IS  BLOCKED  FOR  TERMINAL  1^0.  THE  */ 
/*  ROUTINE  STORES  THE  CURRENT  MACHINE  ENVIRONMENT  IN  *• 
/%   THE   SVAP   STACK  AND   TRANSFERS    CONTROL   TO   THE  */ 

/*    MONITOR  FOR  SELECTION    OF    THE   NEXT   READY  TASK.  */ 

/*    CALLED   BY:    MTS  */ 

f  ^\  *^  rf\  *f>  «7»  *{•*  tf*  *t»  '<*•  -l*  «t*  *r*  *t*  *T*  *f  *  *r*  'Is  fr*  «J*  *r»  *f*  *T*  *r*  *T*  *!"•  *o  »r*  »r»  *r*  »r»  »f»  <T*  *T»  *f»  *T*  >f*  'f*  *f*  "T1  *f^  *T»  **»  *t*  '•»  fT^  *F*  *r»  *T»  *fr  *f*  *t*  *o  *T*  *f*  ^ 

/*    SET  BIT  5    IN    TCTSSTATUS    */ 

DE= . TCTSSTATUS ;     A=TASK;     CALL    C  INDEX]  ; 

M(HL>  =  (A=M(HL>    \    20H)  ; 

/*    SAVE    ENVIRONMENT   */ 

SWAPSSTACK=(HL=SAVE) ;       /#    ONLY   USER  SP    NEEDED   *• 

COTO    [MONITOR] ; 

/*   END   TERHSBLOCK  */ 

EOF 

/«*#*###**:«#*#**:(<#*:;:#   SYSTEM  CALLS    #*#*#****:£*##***#**#/ 

s    5f»  5ft  5ft  5ft  5JC  5f»  5ft  5ft  ».•»  5ft  5jt  5ft  5fC  5ft  5fs  -i*  5ft  5pJ  .-ft  5ft  «ft  5ft  -yC  5ft  rJC  .-ft  5ft  »ft  5jC  .ft  «,••  5»t  5jt  5ft  5fC  5f»  5ft  5f»  5ft  5ft  5f»  5ft  5jZ  5ft  «fC  5ft  5jC  5ft  .,■»  5ft  »y*  5ft  5ft  5ft  /^ 


/*#**#****#**#    INTERMODULE   LINKAGE   MACROS   #*##**#*****/ 

[INT  TB   MB   M23]       [M2B:=0&0OH]     [TB:  =  10O0H1     [MB:=0300H] 

[MACRO  MONITOR    '[HEX  MB   +    8FH] ' j 

[MACRO  INDEX    '[HEX  M2B   +    3H]  '  ] 

[MACRO  INDEX2    '[HEX  M2B   +    0DH3  '  ] 

[MACRO  INDEX4    '[HEX   M2B   +    16H]  '  ] 

[MACRO  INDEX8    '[HEX  M2B  +    24H3  '  ] 

[  MACRO  GET    ' [ HEX   M2B    +    38H]  ' ] 

[MACRO  MOVBUF    '[HEX   M2B    +    41H]'] 

[MACRO  MINISDISK    '[HEX  M2B   +    54HI » ] 

[MACRO  SIZESMSG    '[HEX  TB   +    864H]  '  ] 

[ MACRO  STATUSSMSG    '  [  HEX  TB   +    88CH1 ' ] 

[MACRO  CLEARSSTATUSSLINE    '[HEX  TB   +    827H3 ' ] 

[  MACRO  MTSSMSG    '  [  HEX  TB   +    837H] ' ] 

/**#************    GENERAL   PURPOSE   MACROS    *****#*********/ 

[MACRO   WRITE    '2M 

[MACRO   HARDWARESERROR    '8'] 

•  *****:*:***;**:)<**:*:*#:*#*    DECLARATIONS    J*******:**::*:**:*:******:*:/ 

DECLARE   PLIST  DATA    ( 1 , 0 , 0FFH, OFFH, 0FFH, OFFH) ; 

/##*#####«#***#***    UTILITY  PROCEDURES    ***:.«:###**********/ 

VALSDRIVE:       PROCEDURE; 

/«   THIS   PROCEDURE   VALIDATES   THE   DRIVE   NUMBER    INPUT  TO   */ 
/*    ANY  SYSTEM  CALL   WHICH  REQUIRES   TR4T  PARAMETER.  */ 

S*     INPUT:     A    -    DRIVE    NUMBER   TO    BE    VALIDATED  */ 

•*    OUTPUT:     DRIVE    -    NUMBER   OF    FREE    DRIVE    FOUND  */ 

/*  ERROR  -    ERROR  CODE  */ 

/*    CALLED   BY:    ATTACH  */ 


177 


IF  (A::0FFH)  ZERO  THEN   /*  NO  DRIVE  SPECIFIED  */ 
DO;  S*    SCAN  DRIVE  HAP  FOR  FREE  DRIVE  *S 
DECLARE  LI  LABEL; 

DE=.TCTSDM;  A=TASK;  CALL  [  INDEX81 ; 
B=S; 
REPEAT; 

IF  (A=<M(EL))  ICY  GOTO  LI; 
HL=HL+1; 
UNTIL  (B=B-1)  ZERO; 

/*  NO  DRIVE  AVAILABLE  -  ERROR  10  */ 
ERROR* < A= 10) ;  RETURN; 
Li:  DRIVE=(A=8-B)  ;  /*    FREE  DRIVE  FOUND  */ 
END 
ELSE  IF  (A::8)  !CY  THEN 

/*  DRIVE  NR  >  7  -  ERROR  6  */ 
DO;  ERR0R=(A=6);  RETURN;  END; 
END  VALSDRIVE; 

VALSDISK:   PROCEDURE; 

/-*  THIS  PROCEDURE  VALIDATES  THE  DISK  NUMBER  INPUT  TO  *s 

/*  ANY  SYSTEM  CALL  WHICH  REQUIRES  THAT  PARAMETER.  */ 

/*  INPUT:  A  -  DISK  NUMBER  TO  BE  VALIDATED  */ 

/*  OUTPUT:  DISK  -  NUMBER  OF  FREE  DISK  FOUND  */ 

/#  ERROR  -  ERROR  CODE  */ 

/*  CALLED  BY:  ATTACH  */ 

IF<A::0FFH)  ZERO  THEN   •"*  NO  DISK  SPECIFIED  W/* 
DO;   /*  SCAN  DISK  MAP  FOR  FREE  DISK  */ 
DECLARE  L2  LABEL; 
HL= . DMTSFLAG ;  B=  32 ; 
REPEAT; 

IF  (A=>M(HL))  CY   /*  DISK  AVAILABLE  */ 
(A=>A)  !CY      /*  NOT  IN  USE      */ 
(A=>A)  ICY     /*  NOT  PROTECTED   */ 
(A=>A)   !CY      /*  NOT  RESTRICTED  */ 
THEN  GOTO  L2; 
HL=HL+1 ; 
UNTIL  (B=B-1)  ZERO; 
/*  NO  DISK  AVAILABLE  -  ERROR  2  */ 
ERROR=  (  A=  2 )  ;  RETURN ; 
L2:  DISK=(A=32-B)  ;   /*  FREE  DISK  FOUND  */ 
END 
ELSE  IF  (A:: 32)  !CY  THEN 

/*    DISK  NR  >  31  -  ERROR  4  */ 
DO;  ERR0R=(A=4);  RETURN;  END 
ELSE 

DO;  /*  SEE  IF  SPECIFIED  DISK  AVAILABLE  */ 
DE=. DMTSFLAG;  A=DISK;  CALL  [  INDEX] ; 
IF  (A=>M(HL))  !CY  THEN 

/*  DISK  NOT  AVAILABLE  -  ERROR  2  */ 
DO;  ERR0R=(A=2);  RETURN;  END; 
IF  (A=>A)  CY  THEN 

^*  DISK  IN  USE  -  ERROR  3  */ 
DO;  ERR0R=(A=3);  RETURN;  END; 
END; 
END  VALSDISK; 

VALSKEY:   PROCEDURE; 

/*  THIS  PROCEDURE  COMPARES  THE  KEY  INPUT  AS  A  SYSTEM  */ 

/*  CALL  PARAMETER  WITH  THAT  ASSOCIATED  WITH  A  SPEC I-  */ 

/"*    FIED  VIRTUAL  DISK  FILE.  */ 

/*  INPUT:  PARM  -  VARIABLE  HOLDING  ADDRESS  OF  PARM  KEY  */ 

/*         DISK  -  VIRTUAL  DISK  FILE  NUMBER  */ 

/*  OUTPUT:  ERROR  -  ERROR  CODE  */ 

/*  CALLED  BY:  ATTACH  */ 

DE=.DMTSKEY;  A=DISK;  CALL  [  INDEX4]  ; 
DE=HL;  HL=PARM; 

DO  B=0  BY  B=B+1  WHILE  (A=4;  A::B)   TZERO; 
IF  (A=M(DE);  A::M(HL))  ZERO 
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\    (IF   (A::20H)    ZERO      ( A=M(  HD-OFFH)    ZERO 
THEN  CY= 1    ELSE  CY=0)    CY 
THEN      /*   CHAR  MATCH  */ 
DO; 

DE=DE+1;    HL=HL+1; 
END 
ELSE      /"*    KEY   ERROR  -    ERROR   3    */ 

DO;    ERRCR=(A=5);    RETURN;     END; 
END;    /*    WHILE   */ 
/*   KEYS   MATCH   */ 
END   VALSKEY; 

CLEARSFLAG:       PROCEDURE; 

/*  THIS   PROCEDURE   RESETS   THE    IN   USE   BIT   (BIT    1)  IN           */ 

/*  THE   DMTSFLAG  FOR  A  SPECIFIED   VIRTUAL   DISK.  */ 

z'*  INPUT:    B   -    DISK   NUMBER  */ 

/*  CALLED   BY:    ATTACH,    LOGIN,    CLEARSDM  */ 

DE=. DMTSFLAG;    A=B       1FH;    CALL    [INDEX]; 
M(HL)  =  (A=M(HL)       OFDH)  ; 
END   CLEARSFLAG; 

CLEARSDM:       PROCEDURE; 

/*    THIS    PROCEDURE    RESETS    ALL    ENTRIES    IN    THE    TCTSDM  */ 

/*    ASSOCIATED   WITH   THE   CURRENT   VALUE   OF    TASK.  */ 

/*   CALLED   BY:    LOGIN,    QUIT  */ 

/#**#:;:  if;*:******::::!;  jfctftf  «#*#«#* 

DF=.TCTSDM;     A=TASK;    CALL    [ INBEX8] ; 

M(HL)=OCGH;     C=7; 

REPEAT; 

HL=  HL+ 1 ; 

B=M(HL);     M(HL)=0; 
IF    (A=<B)     CY       (A=<A)      !CY   THEN 
CALL    CLEARSFLAG; 
UNTIL    (C=C-1)     ZERO; 
END   CLEARSDM; 

WRITESBUF:       PROCEDURE; 

/*   THIS   PROCEDURE   CHECKS   THE   MODIFICATION   BIT    IN  */ 

/*    VDCSDRIVE   TO   DETERMINE    IF   THE   CONTENTS   OF   MDBUF  #/ 

/■*    HAVE    BEEN    ALTERED.     IF    SO,     THE    BUFFER    IS    WRITTEN    TO    */ 
/*    THE    MINI-DISK   AND    THE    MOD    BIT    IS    RESET.  */ 

/*    CALLED   BY:    QUIT,    MAP,     LOGIN  */ 

IF    (A=< VDCSDRIVE)     ?CY   RETURN; 
BC= ( EL=  MDSAD)  ;    DE= . MDBUF ; 
L=[  WRITE];    CALL    [MINISDISK]; 
IF    (A: :0)     !ZERO   THEN 

/*    HARDWARE   ERROR   -    ERROR  8   */ 

DO;     ERROR=(A=8);     RETURN;     END; 
VDCSDRIVE=(A= VDCSDRIVE      7FH) ; 
END   WRITESBUF; 

/a:*****************   SYSTEM  ROUTINES   J*******************/ 

ATTACH :       PROCEDURE ; 

/  SJ*  JjC  7f*  5jC ., .  ^»  rfi  If.  ti>.  »|C  rfS  ifs  rj\  *p  *p  ifC  *j*  If;  *f^  iji  .,"C  *jC .+»  »fC  ^fC  >j^  *fC  rf>  »f>  tfc  2|C  «f*  #|*  i|C  »fC  ri>  ^C  *?C  »fs  r^  rfa  j£  ifC  JfC  3fC  JfC  Jf£  rfZ  IjC  *}C  J[I  »js  *fZ  5p  / 

/*   SIMULATE   THE   PHYSICAL   OPERATION   OF   LOADING   DISK  */ 

/*    <DISK  NR>     INTO   DRIVE   <DRIVE   LTR> .  */ 

/*    ARGUMENTS:  *S 

/*       ( 1)     FID    =    0  */ 

/*      (2)    PARI!  =    BASE   ADDRESS    OF    PARAMETER  LIST  */ 

/*  BYTE   0:    DRIVE   NUMBER   (0-7)  */ 

/#  BYTE    l:    DISK  NUMBER   (0-31)  */ 

/*  BYTES    2-5:    PROTECTION    KEY   (0-4    CHARS)  */ 

/*    VALUE:     ERROR   CODE  */ 

BC=(HL=PARM)  ;    DRI  VE=  (  A=M(  BC)  )  ; 
/*   VALIDATE   DRIVE   NR  */ 
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CALL  VALSDRIVE;  IF  (A= ERROR  \  A)  fZERO  RETURN; 
HL=PARM+1;  DISK=  (  A=M(  HL)  )  ; 
/*  VALIDATE  DISK  NR  */ 

CALL  VALSDISK;  IF  (A= ERROR  \  A)  fZERO  RETURN; 
DE= . DMTSFLAG;  A=DISK;  CALL  [INDEX]; 

IF  (A=M(HL)   04H)  TZERO  THEN   /*  DISK  PROTECTED  */ 
DO;  /*   VALIDATE  KEY  */ 
PARM=  (  RL=  PARM+  1 ,  +  1 )  ;  CALL  VALSKEY; 
IF  (A= ERROR  \  A)  'ZERO  THEN 

DO;   •*  NAY  WANT  READ  ONLY  */ 

DE=. DMTSFLAG;  A=DISK;  CALL  [INDEX];  BC=RL; 

IF  <A=M(HL)   08H)  ZERO 

/*  DISK  NOT  RESTRICTED  */ 
S  (HL=PARM;  A=M(HL);  A::0FFH)  'ZERO 
/*  KEY  PARM  NOW- BLANK  */ 
THEN  RETURN    /*  ERROR  VALID  */ 
ELSE 

DO;   /*  SET  UP  READ  ONLY  */ 
M(BC)  =  (A=M(BC)  \  G2H)  ; 

/*  SET  DMTSFLAG  BIT  1  */ 
DISK=(A=DISK  N  40H)  ; 

/*  SET  TCT3DM  BIT  6  */ 
ERROR=(A=0) ; 

/*   CLEAR  ERROR  */ 
END; 
END; 
END; 
/*  MODIFY  DMTSFLAG  */ 

DE=. DMTSFLAG;  A=DISK   1FH;  CALL  [INDEX!; 
M(HL)  =  (A=M(HL)  W  02H)  ;   /*  SET  DMTSFLAG  BIT  1  #/ 
/*    MODIFY  TCT3DM  */ 

DE=.TCTSDM;  A=TASK;  CALL  [  INDEX8]  ; 
DE=HL;  A= DRIVE;  CALL  [INDEX]; 
B=M(HL)  ; 

M(HL)  =  (A=DISK  \  80H)  ;   /*  SET  TCT3DM  BIT  7  *• 
/*  RESET  OLD  DISK'S  IN  USE  BIT  */ 
IF  (A=B   40H)  ZERO  CALL  CLEARSFLAG; 
/*  DISPLAY  STATUS  MSG  */ 
B=(A=  DRIVE);  C=(A=DISK   1FH)  ; 

IF  (A=DISK  40H)   TZERO  THEN  A=72H  ELSE  A= '  '; 
C.\LL  [  STATUSSMSG]  ; 
END  ATTACH; 

LOGIN:   PROCEDURE; 

/*  THIS  SYSTEM  CALL  NOTIFIES  MTS  THAT  THE  REQUESTING  */ 
/*  TERMINAL  IS  NOV  ACTIVE,  AND  SIMULATES  THE  PHYSICAL  */ 
/*  COLD-START  BOOTSTRAP  OPERATION.  TIIE  BOOTSTRAP  LOAD  */ 
S*  TAKES  PLACE  FROM  VIRTUAL  DRIVE  A.  THE  VIRTUAL  DISK  */ 
•*  ATTACHED  TO  THIS  DRIVE  MAY  BE  SPECIFIED  IN  THE  *• 
/*  PARAMETER  LIST,  OR  DISK©  WILL  BE  ASSUMMED  AS  THE  */ 
/*  DEFAULT.  */ 

/*  ARGUMENTS:  */ 

/*      ( 1)  FID  =2  */ 

/*  (2)  PARM  =  BASE  ADDRESS  OF  PARAMETER  LIST  */ 
/*        BYTE  0:  DISK  NUMBER  (0-31)  *s 

/*  BYTES  1-4:  PROTECTION  KEY  (0-4  CHARS)  */ 
/*  VALUE:  ERROR  CODE  */ 

/*  WRITE  MINI-DISK  BUFFER  IF  NECESSARY  */ 

CALL  WRITESBUF; 

IF  (A= ERROR  \  A)  fZERO  RETURN; 

/*  RE- INITIALIZE  TCT  #/ 

CALL  CLEAR3DM; 

DE= .TCT3SIZE;  A=TASK;  CALL  [  INDEX]  ; 

M(HL)=G2;  /*   SIZE  =  16K  */ 

HL=BC+(  DE=  .  TCTSSTATUS)  ; 

M(HL)=1;   •*  SET  BIT  O  */ 

/*  PROCESS  DISK  PARAMETER  */ 

IF  (HL=PARM;  A=M(HL);  A::0FFH)  !ZERO  THEN 

DO;   /*  DISK  SPECIFIED  */ 

EC=5;  DE=HL;  HL= . PLIST(  1 )  ; 
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CALL    [MOVBUFI;     P ARM= ( HL= . PL I ST) ; 

CALL   ATTACH; 

IF    (A= ERROR  \   A)     !ZERO   RETURN; 

END 
ELSE        /*   DISPLAY  DEFAULT  STATUS   MSG  */ 

DO; 

A=72H;    BC=0; 

CALL    t  STATOSSMSG1  ; 

END; 
/*   DISPLAY  SIZE   MSG  */ 
A=16;    CALL    [SIZESMSG]; 
END    LOGIN; 

PROTECT:       PROCEDURE; 

/*  THIS   SYSTEM  CALL   ADDS   THE   READ/WRITE   PROTECTION        */ 

/*  ATTRIBUTE   TO   A  SPECIFIED   VIRTUAL   DISK  FILE.  */ 

/*  ARGUMENTS:  #/ 

/*  ( 1)    FID   =    3  */ 

^#  (2)     PARM   =    BASE    ADDRESS    OF    PARAMETER   LIST  */ 

/*  BYTE   0:    DISK  NUMBER   (0-31)  *• 

/*  BYTES    1-4:    PROTECTION   KEY   (0-4   CHARS)  */ 

/*  VALUE:    ERROR  CODE  */ 

NOP; 

END   PROTECT; 

QUIT:       PROCEDURE; 

^*    THIS    SYSTEM   CALL    NOTIFIES    MTS    THAT   THE  REQUESTING    */ 

/*    TERMINAL    IS    NO   LONGER   ACTIVE.  */ 

/*    ARGUMENTS:  */ 

/*      ( 1)    FID   =4  #/ 

/*       (2)    PARM   =    NONE  */ 

/*   VALUE:    NONE  */ 

f     Jf^  If*  rfi  ?(C  »(C  ifC  *fC  ^P  i,C  JfC  rf\  tf\  *fC  *fC  2fC  Jp,  »f»  ifi  ^fi  if.  *f*  »JC  *fC  7f  .  *j->  JJC  ,»C  «,»  ?f*  •?.  *T»  *P  *T*  3p  *f*  *P  *T*  *V*  '**  *f*  *P  *T*  *I^  »T*  l"  *t»  *T»  Sp  -T»«T-  «T^  «T»  *J»  ,» 

/*    WRITE   MINI-DISK  BUFFER    IF    NECESSARY  */ 

CALL    VRITESBUF; 

IF    (A= ERROR  \   A)     TZERO   THEN 

DO;     E= C HARDWARESERROR] ;    CALL    [ MTSSMSG] ;     END; 
/*    CLEAR   STATUS    LINE    */ 
A=TASK;    CALL    [ CLEARSSTATUSSLINE] ; 
/*    CLEAR  TCT   */ 
CALL   CLEARSDM; 

DE=.TCTSSIZE;    A=TASK;    CALL    [  INDEX]  ; 
M(HL)=32;        /*    SIZE    =     16K   */ 
HL=BC+( DE= . TCTSSTATUS) ; 
M(HL)=0;       /*    RESET  STATUS    BYTE    */ 
GOTO    [MONITOR] ; 
END   QUIT; 

BUMP:       PROCEDURE; 

CALL    VRITESBUF; 

IF    (A= ERROR  \   A)     TZERO  THEN 

DO;    E=  [  HARDWARESERROR] ;    CALL    [MTSSMSG];    END; 
A=TASK;    CALL   [CLEARSSTATUSSLINE]; 
CALL   CLEARSDM; 

DE=.TCTSSIZE;    A=TASK;     CALL    [ INDEXI ; 
M(HL)=32; 

HL=  BC+ ( DE= . TCTSSTATUS) ; 
M(HL)=0; 
END   BUMP; 

RESTRICT:       PROCEDURE; 

/*   THIS   SYSTEM  CALL   ADDS   THE   READ   RESTRICTION   ATTRI-  */ 

/*   BUTE   TO   A  SPECIFIED   PROTECTED   VIRTUAL   DISK  FILE.  */ 

/■*■    ARGUMENTS:  */ 

/*      (  1)    FID   =    5  %/ 

/*       (2)    PARM   =    BASE    ADDRESS    OF    PARAMETER  LIST  */ 

/*  BYTE  O:    DISK  NUMBER   (0-31)  */ 

/*  BYTES    1-4:    PROTECTION    KEY   (0-4    CHARS)  */ 
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/*   VALUE:    ERROR  CODE  */ 

NOP; 

END   RESTRICT; 

SIZE:       PROCEDURE; 

/*   THIS   SYSTEM  CALL   SETS   THE   SIZE   OF   THE   USER'S   SWAP   */ 
/*    IMAGE.  */ 

/*   ARGUMENTS:  */ 

S*      ( 1)    FID   ■    6  *s 

/*      (2)    PARM  =    REQUESTED   SIZE    IN   KILOBYTES  */ 

/*    VALUE:    ERROR  CODE  */ 

/*   COMPARE   REQUESTED   SIZE   WITH   MAX  SIZE   */ 
IF    (A=PARM(0);    A::49)     fCY  THEN 

/*   OUT  OF   BOUNDS   -    ERROR  7   */ 

DO;    ERR0R=(A=7);    RETURN;    END; 
/*    COMPARE    REQUESTED    SIZE    WITH    SWAP    FILE    SIZE    *S 
DE=.TCTSBOE;     A=TASK;     CALL    [ INDEX2] ; 
CALL    [GET];     B=0:     C=  (  A=<  <  PARM(  0)  )  ; 
HL=BC+DE;    STACK=HL;       /*    SAVE   SUM  */ 
DE=.TCT3E0E;    A=TASK;    CALL    C INDEX23 j 
CALL    [GET]  ;    BC=BC+1; 
DE= STACK;       /*   RESTORE   SUM  */ 
A=C-E;    A=B— D; 
IF   MINUS   THEN 

/■*    OUT   OF    BOUNDS    -    ERROR   7    *s 

DO;     ERR0R=(A=7);     RETURN;     END; 
/*    DISPLAY  SIZE    MSG  */ 
A=PARM(0);    CALL    [SIZESMSG]; 
/*   UPDATE   TCT  #/ 

DE=.TCTSSIZE;    A=TASK;    CALL    [INDEX]; 
M(HL)  =  (A=<<PARM(0)>  ; 
END   SIZE; 

UNPROTECT:       PROCEDURE; 

/"*    THIS    SYSTEM   CALL    DELETES    THE    READ    RESTRICTION    AND  XS 

/■#■    READ/ WRITE    PROTECTION    ATTRIBUTES    FROM   A   SPECIFIED  *• 

/*    VIRTUAL   DISK  FILE.  */ 

/*   ARGUMENTS:  *• 

/*      ( 1)    FID   =    7  */ 

/*      (2)     PARM   =    BASE   ADDRESS    OF    PARAMETER  LIST  */ 

/%  BYTE   0:    DISK  NUMBER   (0-31)  */ 

/*  BYTES    1-4:     PROTECTION    KEY    (0-4    CHARS)  */ 

•*    VALUE:    ERROR  CODE  */ 

/  •■•>  »>*vini*^  ■*>••>  *1>  ••>  si*  v!»  ~-t-  ">&•  -V  "-Ir  *fr*  -i*  *i*  *t*  *(>  «J*  «V «4«  ^v^*^**"!"!"!";'  v-  -•'*  -'*  »{*  *fr*  »v  <■>  »->  ->  *-J»  •>  *J*  it*  >•:■*  *{*  ^v-'*  •'*  »r»  "■;»  -~±-  »>     ' 

Z'    *^  «H«  «^  *^  «T»  -^  «T»  »T»  »T»  "T*  »**  "V*  *^  "T»  *v*  *r»  •»■»  •T"  *f^  »N  "T*  *f»  «T*  *J*  "T*  *T»  *f*  *T*  W*  *r»  »T»  »T*  «T»  ***  *f*  'C"  *^  *T»  *T»  *f*  •"**  »f*  "T*  *T*  *f*  «Y»  *V*  *"f»  *<•*  •<*  *(^  "^  «T*  < 

NOP; 

END   UNPROTECT; 


EOF 

/   rf\  *fZ  rf%  rf\  rjZ  *fC  Tj»  *,»  «(*  .fC  ?f»  ifs  *,*  *)C  JfC  -J^  ?(C  *j »  /fC  .[»  rf\  JJC  ?f*  «N  *0  *?"  •**  *T*  *0  »f*  *n  •?*  *T*  **^  *t*  "P  *V*  'I*  *S  »P  *N  3p  Sf"  *P  *P  'T*  »P  *?•  5f5  *T*  H*  *T^  *T^  *V*r 

/*iS******^********:i:*   SERVICE   CALLS    **#****&***#*******#/ 


/*************    INTERMODULE   LINKAGE  MACROS   rfc***********/ 

[INT  M2B   S2B]       [M2B:=O600H]       [S2B:=220OH] 

[MACRO    INDEX   '[REX  M2B   +    3H]  '  ] 

[MACRO    INDEX2    '[HEX  M23   +    0DH1  '  ] 

[MACRO    INDEX8    '[HEX  M2B   +    24H]  '  ] 

[  MACRO   GET    '  [  HEX  M2B   +    38H]  *  ] 

[MACRO   MOVBUF    '[HEX  M2B   +    41H]'] 

[MACRO   MINISDISK   '[HEX  M2B   +    34H]  '  ] 

/■ss:b********»**    GENERAL    PURPOSE    MACROS    ^^*«=P*»:5R*^***^:^:/- 

[  MACRO   READ    ' 1 ' 3 
[MACRO   WRITE    '2'] 
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/*#**:(:*#:{:*****#***   UTILITY  PROCEDURES    *##*****#**#****#/ 
READSBUF:       PROCEDURE; 

/*  THIS   PROCEDURE   READS   A   SPECIFIED   MINI-DISK  SECTOR  */ 

/*  INTO    MDBUF    AND    UPDATES    MDSAD.  */ 

/*  INPUT:     BC    -    MINI-DISK  SECTOR   NUMBER  */ 

/*  OUTPUT:    ERROR  -    ERROR  CODE  */ 

/*  CALLED   BY:    MAP  */ 

DE=. MDBUF;    L=[READ];    CALL   [  MINISDISK]  ; 
IF    (A: :0)     !ZERO   THEN 

/*    HARDWARE   ERROR  -    ERROR  8   */ 

DO;     ERROR=<A=8);     RETURN;     END; 
MDSAD=(HL=BC) ; 
END   READSBUF; 

WRITESBUF:       PROCEDURE; 

/  v>  \lr  •>  •■Li  -.Is  -Ir  »A»  si*  -V  *!•  -£-  ->   ->  *A»  ii>  «.[*  »L»  »[..  >  t-  »i-  -'*  hi*  -t*  *lf  -J'  ">>  *■'*-**  >i*  vA*  -V  -I*  vi»  v[^  »•#  *J*  V>  ^J*  vi»  v>  -J*  vLf  *i>  ij>  •>■«  vj*  -j-  »>  »[*  (If  »'*  *A»  «J»  -.>»     / 

/  *jn  ^f.  >-r»  -i^  *f-  *(>*r*  *o  *r>^*  *T»*f»*T"T>  *f*  -f*^*  *^*T»  »7*  «r»  *f^  *t*  *t**t*  *r*  *T*^*fr  *r»  *r»  *r»«^*r*  Wv^«f»»^*^  .f»  »^»  ^<  *f*  *{■*  -t»  >r.  *f.  *f»  «■{>  *f*  *f*  ^  ^»  ^  / 

/*   THIS   PROCEDURE   CHECKS   THE   MODIFICATION   BIT    IN  */ 

/*    VDCCDRIVE   TO   DETERMINE    IF   THE   CONTENTS   OF   MDBUF  */ 

/*   HAVE   BEEN   ALTERED.     IF   SO,    THE   BUFFER    IS   WRITTEN   TO   */ 
/*    THE    MINI-DISK   AND    THE    MOD    BIT    IS    RESET.  */ 

/*    CALLED    BY:    QUIT,     TiAP ,     LOGIN  */ 

IF    ( A=< VDCSDRIVE)     !CY   RETURN; 
BC=  (  HL=  MDSAD)  ;    DE= . MDBUF ; 
L=[  WRITE];    CALL    [MINISDISK]; 
IF    (A: :0)     IZERO   THEN 

/*    HARDWARE    ERROR  -    ERROR  8   */ 

DO;     EBROR=(A=8);     RETURN;     END; 
VDCSDRIVE=( A=VDCSDRIVE      7FH)  ; 
END    WRITESBUF; 

MAP:       PROCEDURE; 

/*   THIS   PROCEDURE   CALCULATES   THE   RELATIVE   OFFSET  OF   A  */ 

/*    SPECIFIED   VIRTUAL   FLOPPY  DISK  SECTOR    IN    THE   MINI-  */ 

/*   DISK  FILE   AND   THE   BASE   ADDRESS   OF   THAT  SECTOR    IN  */ 

/*    THE    MINI-DISK   BUFFER   AFTER   THE    FILE    IS    READ.     THEN  */ 

/*    IT   CALCULATES    THE    ACTUAL    MINI-DISK   SECTOR   NUMBER  */ 

/*    CONTAINING   THE   ADDRESSED   FLOPPY  DISK  SECTOR,     AND  */ 

/*   COMPARES    IT  WITH   THE   CURRENT  CONTENTS   OF   MDBUF.     IF  */ 

/*    THE   TWO   ARE    NOT  EQUAL,    THE   OLD    BUFFER    IS    WRITTEN  */ 

/*   TO   THE   MINI-DISK  AND   THE   NEWLY  CALCULATED   SECTOR  */ 

/*   NUMBER  READ    IN   TO   REFILL   THE   BUFFER.    A   COMPARISON  */ 

/■*    IS    ALSO    MADE    BETWEEN   THE    CALCULATED    MINI-DISK  */ 

/■*   SECTOR  NUMBER  AND   THE   FILE'S    EOE    VALUE   TO    ENSURE  *• 

/*    THAT  THE   SPECIFIED   VIRTUAL   DISK  SECTOR  ADDRESS    IS  */ 

/*   WITHIN   THE   BOUNDS   OF   THE   FILE.  */ 

/*    INPUT:    VDCSTRACK  -    FLOPPY  DISK  TRACK  NUMBER  */ 

/*  VDCSSECTOR  -   FLOPPY  DISK  SECTOR  NUMBER  */ 

/*   OUTPUT:    BC    =     128   =    FLOPPY  DISK  SECTOR  SIZE  */ 

/*  HL    =    BASE    ADDRESS    OF    FLOPPY   DISK   SECTOR  *^ 

/*  IN   BUFFER  */ 

/*    CALLED   BY:    READSFLOPPY,    WRITESFLOPPY  */ 

DECLARE   BUFAD   DATA    (0,0); 

DECLARE   SECNR  DATA   (0.0); 

/*    MULTIPLY  TRACK  NUMBER  BY  26    */ 

D=(A=  VDCSTRACK)  ; 

E= ( A=  VDCSSECTOR)  ; 

B=0i     C=26;     H=8; 

C=(A=>C)  i 

REPEAT ; 

If'cY  THEN   A=B+D; 

CY=0;    B=(A=>A); 

C=(  A=>C)  ; 
UNTIL    (H=H-1)    ZERO;  /*   BC   =    26   *   TRACK  */ 

/*    ADD   SECTOR  NUMBER  TO   26    *   TRACK  */ 
C=(A=C+E);    B=(A=B++0); 
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/*    BC    =    26    *    TRACK   +    SECTOR  */ 
/*    DIVIDE    26    *    TRACK  +    SECTOR   BY  4    *• 
DE=0; 

CY=0;    B=(A=>B);    C=(A=>C);    E=(A=>E); 
CY=0;    B=(A=>B);    C=(A=>C);    D=(A=<D); 
/*    BC    =    BC    /    4    */ 

/*   DE   =    RELATIVE   BUFFER  ADDRESS   */ 
BUFAD=(HL=DE) ;       /*   SAVE   RELATIVE   BUFFER  ADDRESS   */ 
s*    CALCULATE    AND    SAVE    NEW   MINI -DISK   SECTOR   NR  */ 
SECNR= ( HL= VDCSBOE   +    BC) ; 

/*    COMPARE   NEW  SECTOR   NR  WITH   VDCSEOE   */ 
A=VDCSEOE<  1)-L;    A=VBCSEOE(0) — H; 
IF   MINUS   THEN 

/%   OUT  OF   BOUNDS   -    ERROR  7   */ 

DO;    ERR0R=(A=7);    RETURN;    END; 
/*   COMPARE   NEW  SECTOR  NR  WITH   MDSAD   */ 
IF    <A=MDSAD(0);    A::H)     !ZERO   THEN 

CY=0 
ELSE    IF    (A=MDSAD(1);     A::L)     !ZERO    THEN 
CY=0 

ELSE   CY=1; 
/*   WRITE   OLD   SECTOR  AND   READ   NEW   IF    NECESSARY  #/ 
IF    fCY  THEN 

DO;       /*    NOT  EQUAL   */ 

CALL    WRITESBUF; 

IF    (A=  ERROR  \    A)     !ZERO   RETURN; 

BC=(HL=SECNR) ;    CALL   READSBUF; 

IF    <A=ERROR  N    A)      TZERO    RETURN; 

END; 
/%   SET   UP    REGISTERS    FOR  RETURN   */ 
BC=123;    DE=(HL=BUFAD)  ; 
END    M4P; 

/^jS***************:;:    SERVICE   ROUTINES    #*»*********:**#***/ 
WRITESPRIiYTER:       PROCEDURE; 

/  "■>  St*  *t*  "-'*  '■'  •■'*-!*  ■>  <*  -J»  ->■  ^V  *4*  *(*  -J>  '•'  v>  v>  •..$*  *■■*  ^i*  -■>  »>■'/  O*  «l-»  "if  S(»  -'-  v>«  vfr»  •.ir  -^r  «,/*  ■>  *Vvl',i',l"i"^  vl*«'«-  »>  %>+t?  *('■*  »f**J*  *+*  «>«»*■«.'»     / 

/  ^S  ^  *^^fi»S  W»  *n  »N  -t^  ^  *i»  •o  ^  n^H^^t*  n*  *o  *^  *T>«fr  *r>  •*I>*J*  'N*J*  "T*^  »f*  *r»  *N  *t*  •T*^  «^^*t»  •^•^  H^  •^•^  ^*  •,I*-t»  ^  ^  *3«-J^^^  »!*  W»  *v>  *v*  / 

/*   THIS   SERVICE   CALL    IS   CALLED  TO   WRITE   A  SINGLE  */ 

/*    CHARACTER  TO    THE    SERIAL    PRINTER.  */ 

/*    ARGUMENTS:  */ 

/*      ( 1)    FID   =11  */ 

/*       (2)    PARM  =    ASCII    CHARACTER  */ 

/*   VALUE:    ERROR  CODE  */ 

/  \lf  »'»  -'>  *J^  ->  -i-  .•*«*»».'*  O*  •Jt  •>  hj^  Kty  Oh*  »1»  it.  .1*  »•*  «i»  >l<iilslf  <ia  sU  vl*  *i*  *i*  «i»  »•*  «J*  «  >•*?»  v(*  -'*  *i»  «+•  «>  -  V  *iif  «b  *J#  vj*  O*  -J*  «J>  »Ji»  *s.  «J#  vi*  ^  •»  vf,  •.  V  -  ■-      y- 

/  if*  *^  *^  *7*  #f»  *^  «t*  ■'P*  «t*  *f*  *t*  *F*  *T*  *t»  *l*  *o  *T*  <f*  i*  *r»  '■r»  ■+»  *T»»T»*^  W*  "T*  •f*  *r*  *1»  «r»^*  W^  n*  »l*  *r*  *t*  *f*  W*  «r»  •t*  ^»  *<»  *r»  "T*  *T*  *o  *o  •**  *T*W**t»  *v*  *r»  r 

NOP; 

END   WRITESPRINl-ER; 

SELECTS DRIVE:        PROCEDURE; 

/*    THIS    SERVICE   CALL   SELECTS    THE    VIRTUAL  FLOPPY  DISK      */ 

/*   DRIVE   TO   BE   USED   FOR  SUBSEQUENT   FLOPPY  DISK  */ 

/*   ACCESSES.  */ 

/*    ARGUMENTS:  */ 

/*      ( 1)    FID   =    12  */ 

/*       (2)     PARM   =    DRIVE    NUMBER    (0-7)  */' 

/*    VALUE:    ERROR   CODE  */ 

DRIVE=(A=PARM(  1)  )  ; 

/*    VALIDATE   DRIVE   NUMBER  */ 

IF    (A: :8)     !CY  THEN 

/*   DRIVE   NR  >    7   -    ERROR  6    */ 

DO;     ERR0R=(A=6);     RETURN;    END; 
/*    VALIDATE   THAT   DRIVE    IN    USE   */ 
DE=.TCT3DM;     A=TASK;     CALL    C INDEXS] ; 
DE=HL;     A=DRIVE;     CALL    [INDEX]; 
IF    (A=<M(HL))     ?CY  THEN 

/*    DRIVE   NOT   AVAIL   -    ERROR    10   */ 

DO;    ERR0R=(A=10) ;    RETURN;    END; 
/*    UPDATE   VDC    BLOCK  */ 
DISK=(A=M(HL)        IFH); 
IF    (A=M(HL>       40H)     !ZERO   THEN      /*   READ   ONLY  */ 

DRIVE=(A= DRIVE   \    40H) ;       /*    SET   BIT   6    */ 
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DE=.DMTSBOE;    A=DISK;    CALL    [  INDEX2] ; 
CALL    [GET];    VDCSBOE=( HL=BC) ; 
DE=.DMTSEQE;    A=DISK;    CALL    [  INDEX2] ; 
CALL    [ GET] ;    VDCSEOE= ( HL=  BC) ; 
VDCSDRIVE=(A= DRIVE)  ; 
END   SELECTSDRIVE; 

SETSDMA:       PROCEDURE; 

f*  THIS    SERVICE    CALL    SETS    THE    ADDRESS    OF    THE    120    BYTE    */ 

/*  DMA   BUFFER  TO   BE   USED    IN  SUBSEQUENT  VIRTUAL   FLOPPY  */ 

/%  DISK  ACCESSES.  */ 

/*  ARGUMENTS:  */ 

/*      ( 1)    FID   =    13  */ 

/*      (2)    PARM  =    DMA   ADDRESS  */ 

/-*  VALUE:     ERROR   CODE  *r 

A=PARM(l)-0;     A=PARM(0) — 40H; 
IF    MINUS    THEN 

/*   OUT  OF   BOUNDS   -   ERROR  7   */ 

DO;    ERR0R=(A=7);     RETURN;    END; 
VDCSDMA=  (  HL=  PARM)  ; 
END   SETS DMA; 

SETSTRACK:       PROCEDURE; 

S*    THIS    SERVICE    CALL    SETS    THE    TRACK   NUMBER   TO    BE    USED  *^ 

/*     IN    SUBSEQUENT   VIRTUAL    FLOPPY   DISK  ACCESSES.  */ 

/*    ARGUMENTS:  */ 

/*       ( 1)     FID   =     14  */ 

/*      (2)    PARM  =    TRACK  NUMBER  */ 

/*    VALUE:    NONE  */ 

VDCSTRACK=  (  A=  PARIK  1 )  )  : 
END   SETSTRACK; 

SETSSECTOR:       PROCEDURE; 

/*   THIS   SERVICE   CALL   SETS   THE   SECTOR  NUMBER  TO   BE  *• 

/*    USED    IN   SUBSEQUENT  VIRTUAL   FLOPPY  DISK  ACCESSES.  */ 

/*   ARGUMENTS:  */ 

/"*       <  1)     FID    =     15  */■ 

/*      (2)    PARM  =    SECTOR  NUMBER   (1-26)  */ 

/*    VALUE:    ERROR  CODE  */ 

A=PARM(  1)  ; 

IF    (A:: 27)     !CY      \    (A::0)    ZERO   THEN 

/*    OUT   OF    BOUNDS    -    ERROR  7    */ 

DO;    ERR0R=(A=7);    RETURN;    END; 
VDCSSECTOR=A; 
END    SETSSECTOR; 

READSFLOPPY:       PROCEDURE; 

*  str  •£»  «.!'  «-i*  »i»  •■}*  »*»  -»»  -i»  •■'*  «J»  -i-  »[*  tV  *J»  »k  -J-  »>•  *>•  »>  vi-  -I*  »J*  »i»  »J*  >.t-  -J*-  i>  -V  -V  «J*  ».>■  »'*  *>J-*  -£-  *i*  ***--*"  "P  *!•■  *^  ^  -t»  '•i*  *+"  -J*  *'*  •J'  *±»  *£»  *V  »1»  *■!•  *i»  X 
/    «f*  *f»  •*■•  *f*  *f*  *T*  H*  *■*  *»*  •f*  *■*  *!*  *?■  *v»  •T*  *T»  If*  *f*  ^*  "T*  "T>  "T*  *f*  *T»  »T*  *T»  "T*  *T»  *T»  *v»  »T*  *t*  *"%  ■(*  *T*  *T*  *T*  ■(■  *»*  *v>  if*  Ifl  if*  "T*  *T»  *T*  *f*  *V"  if*  •V*  •§*  •T*  >f*  if*  ^ 

/*   THIS   SERICE   CALL   SIMULATES   READING  FROM  A  FLOPPY  */ 

/*   DISK.    THE   VIRTUAL   DISK  SECTOR  AND  TRACK  SPECIFIED  */ 

/*    IN   THE   VDC   BLOCK    IS   READ   FROM  THE   SPECIFIED  */ 

/*    VIRTUAL   DRIVE    INTO   A    128  BYTE   BUFFER    IN   THE   USER'S  */ 

S*   SWAP    AREA.  */ 

/#    ARGUMENTS:  */ 

/*      ( 1)    FID   =16  */ 

/*      (2)    PARM  =    NONE  */ 

/*  DRIVE.    SECTOR,    TRACK,    AND   DMA  ADDRESS   MUST  */ 

/*  HAVE   BEEN   PREVIOUSLY  SET  BY  CALLS   TO   THE  */ 

/*  APPROPRIATE   PROCEDURES.  */ 

/"*    VALUE:     ERROR   CODE  *• 

CALL    MAP; 

IF    (A= ERROR  \    A)     JZERO   RETURN; 
DE=HL;    HL=VDCSDMA;    CALL    [MOVBUF]; 
END   READSFLOPPY; 


185 


VRITESFLOPPY:   PROCEDURE; 

S#  THIS  SERVICE  GALL  SIMULATES  WRITING  TO  A  FLOPPY  */ 

/*  DISK.  A  128  BYTE  BUFFER  IN  THE  USER  SWAP  AREA  IS  */ 

/*  WRITTEN  TO  THE  VIRTUAL  TRACK,  SECTOR,  AND  DRIVE  */ 

/*  SPECIFIED  IN  THE  VDC  BLOCK.  */ 

/*  ARGUMENTS:  */ 

/*   ( 1)  FID  =  17  *• 

/*   <2>  PARP1  ■  NONE  */■ 

/*       DRIVE,  SECTOR,  TRACK,  AND  DMA  ADDRESS  MUST  */ 

/*       HAVE  EEEN  PREVIOUSLY  SPECIFIED  BY  CALLS  TO  */ 

/*       THE  APPROPRIATE  PROCEDURES.  */ 

/*  VALUE:  ERROR  CODE  */ 

CALL  MAP; 

IF  (A= ERROR  \  A)  !ZERO  RETURN; 

STACK=HL;  DE= ( HL= VDCSDMA) ; 

HL=STACK;  CALL  [MOVBUF3; 

VDCSDRIVE=(A=VDCSDRIVE  \  80H) ;   /*  SET  BIT  7  */ 

END  WRITE8FL0PPY; 

EOF 


186 


/  Si*  V  si*  *s>  si*  si*  sf*  *l»  4*  ~A*  *■/*  *J*  si*  *''  *I*  VI*  y  '■*  vi-'  *-t*  * I*  s|»  \V  sl#  »i»  vl-»  1 1»  vi»  sj*  vl*«J*  » V  »J*  -A"  't»  *1*  "J*  ^4*  »i*  ->J*  «A»  » t*  sir  si*  si*  si*  v>  si*  •.»*  «1*  +>-  sl*^sV  S 

/  A*  ^N  w»  'T-  •!(-  *^*J»  »^  »r*  "^  *N  W*  *f* *r* ^  »o  ♦•t*  *c»  *i» *?*  «ts  *c* *T"  'r»  *N*J>*t»  -t>  n* *f>  *p *P *f* "T*  ^  *p  *^ *T*  *^«f*  *n  ^**r*  *T»n»  *^  ■^s*T>*T**^^*^ 

/#*##*#*#####      TERMINAL    INTERFACE   MODULE      ****#******/ 

/*  */ 

/*  TERMINAL    INTERFACE    MODULE    PROVIDES    THE    MTS       */ 

/*  INTERFACE    WITH   THE    FOUR  DISPLAY   TERMINALS                       */ 

/*  ATTACHED   TO   THE   SYCOR  440    SYSTEM.       THE   MODULE    IS    */ 

/*  SEPARATED    INTO   FIVE   BASIC    SUBMODULES.       EACH                 */ 

/*  SUBMODULE   CONTAINS    THE   MACROS    NECESSARY  FOR                */ 

/*  LINKING   WITHIN    THE   TERMINAL   MODULE   AND   FOR                   */ 

/*  EXTERNAL   MTS   LINKAGE.                                                                        */ 

/*  ■*./ 

•*  (1)    DATA   DECLARATIONS                                                                        */ 

/*  THIS    SUBMODULE    PROVIDES    ALL   DECLARATIONS   OF    */ 

/*  THE   DATA  STRUCTURES   UTILIZED  BY  THE  TERMINAL*/ 

/*  MODULE.                                                                                               */ 

/*  (2)    UTILITY  PROCEDURES                                                                  */ 

/*  THIS   SUBMODULE   CONTAINS   THE   BASIC   UTILITY        */ 

/■*  PROCEDURES    WHICH    PROVIDE    COMMON    REGISTER            */ 

/*  MANIPULATION   AND    PROCESSING   REQUIRED   BY              */ 

/*  MANY  PROCEDURES   THROUGHOUT   THE   REMAINDER           */ 

/*  OF   THE   TERMINAL    INTERFACE   MODULE.                              */ 

/#  *    COMPARESPTRS                 *    GETS  INDEX                        */ 

/*  *    GETSVALUE                         *    ST0RE3VALUE                   */ 

/*  '■:-.   C0NVERT3NUMBR3T03ASCII                                          */ 

/*  *    H0VE33YTES                       *    SWAF3CURS0R                    */ 

/*  (3)     TERMINAL    INTERFACE    PRIMITIVES                                           */ 

/*  THIS    SUBMODULE   CONTAINS    THE   PROCEDURES    WHICH*/ 

/*  PROVIDE   THE   BASIC   TERMINAL    INTERFACE                     */ 

/*  FUNCTIONS.                                                                                        */ 

/*  #    BLANKSDISPLAY              *    GET3D I SPLAYS ADDR      */ 

/*  *    CHECK3CURSQR                *    GETSTERM3STATUS         */ 

/*  *    SCR0LL3DISPLAY            *    SENDSBEEP                          */ 

/*  *    SENDSCLICK                      *    UPDATESCURSOR              */ 

/*  *    GETSSTATUSSADDR                                                              */ 

/*  (4)    KEY  PROCESSING   PROCEDURES                                                 */ 

/*  THIS    SUBMODULE   CONTAINS    THE    PROCEDURES    WHICH*/ 

/*  PROVIDE   THE   BASIC   TERMINAL    INPUT   PROCESSING.*/ 

/*  THEY   ARE    CALLED    TO    PROCESS    EACH    KEY   ENTERED    */ 

/*  AT   A   TERMINAL.       THEIR   FUNCTIONS    INCLUDE:            */ 

/*  CHECKING   FOR  AND   CONVERTING  LOWER  TO   UPPER      */ 

/*  CASE   LETTERS    IF   REQUIRED;    CHECKING   FOR  ANY      */ 

/*  KEY  COMMANDS    (WHICH    INCLUDES   ALL   LINE                  */ 

/*  EDITING);    AND    IF    NOT   A   KEY  COMMAND,                          */ 

/*  DISPLAYING   THE    INPUT  CHAR  AT  THE   TERMINAL.       */ 

/*  *    KEYSCOMMAND         *    TERMS INFUT3CNTL                    */ 

/*  (5)     TERMINAL    INTERFACE   SYSTEM   FUNCTIONS                          */ 

/*  THIS    SUBMODULE   CONTAINS    THE   PROCEDURES    WHICH*/ 

/*  PROVIDE   THE   PROCESSING   REQUIRED   TO    INTERFACE*/ 

/*  THE   TERMINAL   WITH   THE   REST   OF   THE   MTS                   */ 

/*  MODULES.        IT   PROVIDES    READING   AND   WRITING         */ 

/*  OF   CHARACTERS   FROM/TO  THE   TERMINALS;                      */ 

/*  TERMINAL    STATUS    INFORMATION    (E.G.     WHETHER         */ 

/*  THERE'S    INPUT   AVAILABLE    OR   NOT);    AND    DISPLAY*/ 

/*  OF    STATUS    AND   MTS    MESSAGES    ON   THE   TERMINAL      */ 

/*  STATUS   LINE.                                                                                   */ 

/*  *    BLINKSCURSORS              *    CLEAR3STATUSSLINE   */ 

/*  *   TERMINALSSTATUS        *   READSTERMINAL             */ 

/*  *   WRITESTERMINAL           *   STATUSSMSG                     */ 

/"*  *    MTS3MSG                               *    SIZE3MSG                             */ 
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/###****##*#*   TERMINAL  DISPLAY  DESIGN   *###*#*#***##/ 

/*  */ 

/#  */ 

/*                 GENERAL  FORMAT  OF  EACH  TERMINAL  DISPLAY  */ 

/*  */ 

/*  */ 

/*       %/ 

/*                 10            STATUS  LINE              631  */ 

/*       */ 

/*                 */ 

/#       10      D                               63  1  */ 

/*       */ 

/*                 164         I                         1271  #/ 

/*       */ 

/*       1128    B        S                     1911  */ 

/*       ^/ 

•*       I  192        U        P                 255  I  */ 

/#       #/ 

/*       1256            F        L             319  1  */ 

/*       %/ 

/*       1320                F        A        3831  */ 

/*       #/ 

/*        1 384                      E        Y     447  I  */ 

/*       */ 

/•*                  1448                          R         5111  */ 

/*       */ 

/%  ■*■/ 

/*  %/ 

/*                   STATUS  LINE  */ 

z^       vr,/- 

/*       1 0       VFD        39  1 40  MS  47 1 43  KSG  63  I  */ 

/*       */ 

/*       WHERE  */ 

/*      VFD  -  VIRTUAL  FLOPPY  DISK  STATUS  DISPLAY;  */ 

/#            CONTAINS  THE  INFORMATION  ASSOCIATED  */ 

/*            WITH  THE  CURRENT  TERMINAL  USER'S  */ 

St*                                 VIRTUAL  FLOPPY  DISK  DRIVE  AND  DISK  */ 

/*            NUMBER  ASSIGNMENTS.  (SEE  STATUSSMSC  *• 

/*                              PROC  FOR  DETAILS)  */ 

/#       MS  -  DISPLAY  OF  THE  MEMORY  SIZE  THE  USER  */ 

/*            HAS  REQUESTED.  (SEE  SIZESMSG  PROC)  */ 

/*      MSG  -  DISPLAY  AREA  FOR  MTS  MESSAGES  WHICH  */ 

/*            ARE  DISPLAYED  IN  RESPONSE  TO  A  */ 

/*             SYSTEM  OR  SERVICE  CALL  TO  MTS.  */ 

/*            (SEE  MTSSMSG  PROC)  */ 

/*  #/ 

/#  #/ 

/*                   DISPLAY  BUFFER  */ 

/#                   */ 

/■*  *•/ 

/*  THE  DISPLAY  BUFFER  IS  VIEWED  AS  A  SINGLE  */ 
/*  BUFFER  FROM  0  TO  512  BYTES  IN  LENGTH.   THERE  ARE  */ 

/*  FOUR  DISPLAY  BUFFER  POINTERS  WHICH  PROVIDE  THE  */ 
/*  CONTROL  OF  INPUT  FROM  AND  OUTPUT  TO  THE  TERMINAL  */ 

/*  DISPLAY.   THESE  POINTERS  ARE:   CURRENTSLINE;  */ 

/*  CURSOR;  NEXTSCHAR;  AND  ENDSIBUFF.  */ 

/*  EACH  POINTER  UTILIZES  TWO  BYTES  OF  STORAGE  TO  */ 

/*  ACCOMMODATE  A  RANGE  IN  VALUE  FROM  0  TO  512.  */ 

/*  IN  ADDITION  TO  THESE  POINTERS,  THERE  IS  A  */ 

/*  TERMINAL  STATUS  BYTE,  CALLED  TERMSSTATUS,  */ 

/*  ASSOCIATED  WITH  EACH  TERMINAL.   IT  IS  SET  TO  */ 

/*  ONE  OF  THREE  VALUES:   INPUTSWAITING;  */ 

/#  MTSSCMDSREADY;  IBUFFSEMPTY.   THESE  ARE  THE  */ 

/*  PRIMARY  DATA  STRUCTURES  PROVIDING  TERMINAL  I/O  */ 

/*  CONTROL.  */ 

/*  */ 

/*  THE  PRIMARY  SYCOR  HARDWARE  CHARACTERISTIC  WHICH  */ 

/*  AFFECTED  THE  MTS  TERMINAL  INTERFACE  WAS  THE  */ 
/■*■    RELATIVELY  SLOW  MINI-DISK  ACCESS  TIMES.   THIS  HAS*/ 

/*  A  MAJOR  IMPACT  WHEN  TRYING  TO  DESIGN  AN  */ 
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/*  INTERACT I VE  TIMESRARED  SYSTEM.  INORDER  TO  */ 
/*  PROVIDE  REASONABLE  INTERACTIVE  RESPONSE  TIMES  */ 
/*  TO  USER  ACTIONS,  THE  TERMINAL  INTERFACE  */ 

/*  MODULE  PROVIDES  ALL  LINE  EDITING  FEATURES  FOR  */ 
/*  THE  USER  PRIOR  TO  TRANSFER I NG  ANY  DATA  TO  THE  */ 
/*  USER'S  PROGRAM.  (SEE  KEYSCOMMAND  PROC)  */ 

/*  THE  TERMINAL,  DISPLAY  DESIGN  UTTLITZES  TWO  */ 

/*  SEPARATE  BUFFERS  TO  PROVIDE  THE  USER  WITH  THE  */ 
/*  CAPABILITY  OF  CONTINUING  TO  ENTER  DATA  PRIOR  */ 
/*  TO  THE  USER'S  PROGRAM  BEING  SWAPPED  IN  TO  *• 
/*  PROCESS  THE  PREVIOUS  INPUT  LINE.  */ 

/*  THE  FIRST  BUFFER  IS  CALLED  THE  'CURRENT  LINE'  */ 
/*  AND  CONTAINS  THE  INPUT  DATA  WHICH  IS  CURRENTLY  */ 
/*  BEING  ENTERED  BY  THE  USER.  THE  CURRENT  LINE  CAN  */ 
/*  RANGE  FROM  0  TO  512  BYTES  IN  LENGTH.  THIS  IS  THE*/ 
/*  DATA  THAT  IS  AFFECTED  BY  ANY  LINE  EDITING  COMMAND*/ 
/*  ENTERED  BY  THE  USER.  */ 

/*  THE  SECOND  BUFFER  IS  THE  INPUT  LINE  OR  BUFFER.  */ 
/*  THE  CURRENT  LINE  BECOMES  THE  INPUT  LINE  WHENEVER  */ 
/*  A  CARRIAGE  RETURN  OR  ERROR  RESET  (  MTS  COMMAND  */ 
/*  KEY)  IS  ENTERED.  THIS  ACTION  ALSO  ESTABLISHES  */ 
/*  A  NEW  CURRENT  LINE.  THE  INPUT  LINE  CONTAINS  THE  */ 
/*  THE  DATA  WHICH  IS  TRANSFERRED  TO  THE  USER  PROGRAM*/ 
/*  WHEN  REQUESTED.  THUS  THERE  CAN  BE  AN  INPUT  LINE  */ 
/*  AND  A  CURRENT  LINE  ESTABLISHED  AT  ONE  TIME.  */ 
/*  THE  CURRENT  CURSOR  POSITION  ALWAYS  SPECIFIES  */ 
/*  WHERE  THE  NEXT  CHARACTER  WILL  BE  ENTERED,  ON  #/ 
/*  INPUT,  AND  WHERE  THE  NEXT  CHARACTER  WILL  BE  */ 
/*  DISPLAYED  DURING  OUTPUT.  */ 

/*  */ 

/*  THE  FOLLOWING  IS  AN  EXAMPLE  OF  POINTER  */ 

/*  MANIPULATION  DURING  INPUT:  */ 

/*   INITIALIZATION  OR  CLEAR  SCREEN  CMD:  */ 

/*       ALL  POINTERS  ARE  SET  TO  ZERO  AND  */ 

/*       TERMSSTATUS  =  INPUT  BUFFER  EMPTY.  */ 

/*   USER  ENTERS  DATA  -  "SAMPLE  INPUT  DATA":  */ 

/*  CURRENTSLINE  POINTS  TO  THE  STARTING  POSITION*/ 
/*  AND  CURSOR  ALWAYS  POINTS  TO  THE  NEXT  */ 
/*  POSITION  TO  FILL.  NOTE  THAT  AT  THIS  POINT  */ 
/*  ONLY  CURSOR  HAS  BEEN  MODIFIED.  FOR  THE  */ 
/*  INPUT  DATA  ABOVE  IT  WOULD  BE  POINTING  TO  */ 
/*       DISPLAY  BUFFER  POSITION  17.  */ 

/*  USER  TERMINATES  CURRENT  LINE  (I.E.  ENTERS  CR  OR  */ 
/*   MTSSCMD) :  */ 

/*  ENDS  I BUFF  IS  SET  TO  CURRENT  CURSOR  POSITION.*/ 
/*  CURSOR  IS  SET  TO  LEFT  MOST  POSITION  OF  NEXT  */ 
/*  LINE  ON  DISPLAY.  */ 

/*  CURRENTSLINE  IS  SET  TO  NEW  CURSOR  POSITION.  */ 
/*       TERMSSTATUS  IS  SET  TO  INPUT  WAITING.  */ 

/*  */ 

/*  THE  RESULTING  POINTER  POSITIONS  ARE  SHOWN  FOR  THE*/ 
/*  SAMPLE  INPUT  DATA  AND  CR  CHARACTERS  ENTERED.  */ 
/*  (WHERE  *  =  CURRENT  CURSOR  POSITION)  */ 

/*  */ 

/*       NC  EIB  */ 

/*       */ 

/*       I  SAMPLE  INPUT  DATA  I     */ 

/*       */ 

/*       I*  I     */ 

/*       */ 

/*       CL  */ 

/*  */ 

/*  THE  SAMPLE  INPUT  DATA  IS  NOW  AVAILABLE  FOR  THE  */ 
/*  USER'S  PROGRAM  WHEN  IT'S  TIMESLICE  COMES  UP.  */ 
/*  THE  NEXTSCHAR  (NC)  POINTER  SPECIFIES  THE  NEXT  */ 
/*  CHARACTER  TO  BE  READ  AND  RETURNED  TO  THE  USER  */ 
/*  PROGRAM.  WHEN  NEXTSCHAR  =  ENDS  I BUFF,  A  CARRIAGE  */ 
/*  RETURN  (CR)  IS  RETURNED  TO  THE  CALLING  USER  */ 
/*  PROGRAM.  */ 

/*  THERE  ARE  THREE  OCCASIONS  WHEN  THE  NEXTSCHAR  */ 
/*  POINTER  IS  RESET  EQUAL  TO  THE  CURRENTSLINE  */ 
/*  POINTER:  */ 
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/*      (1)    FOR  A  CLEAR  SCREEN   COMMAND.  */ 

/*       (2)     WHEN    READ3TERMINAL    PROC    DETECTS    THAT  THE  *• 

/*  END    OF    THE    INPUT   BUFFER   HAS    BEEN    REACHED.  */ 

/*      (3)    WHEN   WRITESTERMINAL   PROC    OUTPUTS    CHARACTERS  */ 

/*  TO   THE   TERMINAL   FROM  THE   USER'S    PR0GR4M.  */ 

/sft  */ 

/*   THE   OUTPUT  OF    DATA   FROM  THE    USER'S    PROGRAM  TO  */ 

/*   THE   TERMINAL   RESULTS    IN   THE   FOLLOWING:  *,' 

/"*       (1)    THE    CHARACTER    IS    DISPLAYED    AT   THE    CURRENT  */ 

/*  CURSOR  POSITION.  */ 

/*       (2)    THE   CURSOR  POSITION    IS    INCREMENTED.  */ 

/*      (3)    THE   CURRENTSLINE   AND   NEXTSCnAR  POINTERS   ARE  */ 

/*  SET  EQUAL  TO   THE   NEW  CURSOR  POSITION.  */ 

/*      (4)    THE   TERMINAL  STATUS    IS   SET  TO   EMPTY.  */ 

/*  %/ 

sx  */ 

/*    ANOTHER   DESIGN   CONSIDERATION    WAS    THE    REQUIREMENT  */ 

/*    FOR  THE   TERMINAL   MODULE   TO   PROVIDE   A   BLINKING  */ 

/*    CURSOR  DISPLAY  AT   EACH   TERMINAL.       THIS    REQUIRED  */ 

/*   SPECIAL   PROCESSING  TO   ENSURE   THAT  THE   CURSOR  */ 

/*   CHARACTER   (05FH)    DID   NOT  GET  LOST  DURING  THE  */ 

/*    CURSOR  UPDATE   AND   MANIPULATION    FUNCTIONS  */ 

/■*    ACCOMPLISHED    BY  THE    KEY   PROCESSING    AND    SYSTEM  *• 

/*    FUNCTION   SUBMODULES.    CnECKSCURSOR   PROC( PRIMITIVE  */ 

/*   SUBMODULE)    PROVIDES    THIS    FUNCTION.  */ 

/*  #/ 

/*  *• 


/**:;:**      TERMINAL    INTERFACE   DATA   DECLARATIONS      *******/ 


[MACRO    IBUFFSEMPTY      '0'        ] 
[MACRO   CURSORSCHAR      '5FH'J 

• *U  «J*  -»A»  »(*■  *lf  sif  i>  •(*  %U  ^*-  >J*  »J>  *Jf*if  *i»  "4?*j?*l?  "J?  *i*^  *Jf*&  *£*  *fe?  4f  *&*fe*Jl?  ^*jT^f  vf"*  ^*  >!?  "&  "btf  *^T  ^V  *J^  ^V  *tt?*2?*i*  ^*^i*  +>*i*+4?+tr*&?+J?    S 
f    *f*  *,»  r\*  r(--4^~  »f»  »f*  rft  *J.  <^  «7*  ^T*  *fs  *fs  «f.  *(-.  sfs  *f\  «fs  *f.  *Jx  •<"•  ^f*  ^1^  »?*  *f»  rf%  rf*  ^s  *Jn  *f^  *f\  >|>  *f>  rff*  'T*  *T"«'r*  "V*  *f*  •¥•  W^*V*  *V*  >f*  'r-  *r»  "1  ■  "T*  *f*  *T»A*  • 

/*#*****#*      TERMINAL    INTERFACE  DECLARATIONS      ********/ 

/"*    ASCII    -    CONTAINS    DATA    FOR  MATRIX   CODE    TO   ASCII*/ 
/*  CONVERSION.  */ 

DECLARE   ASCII    DATA    ( 1EH, 1CH, 1BH, SDH, 5BH, 29H, 28H, 7FH, 
26H, 3DH, 25H, 24H, 23H, 40H, 21H, 2AH. OAH, 0CH, OBH, 0A0H, 
0DH,50H,4FH, 15H, 55H, 59H, 54H, 52H, 45H,37H, 5 1H, 49H, 
0DH, 9 , 3 1H, 9 , 22H, 3AH, 4CH, ODH, 4AH, 48H, 47H, 46H, 44H, 53H, 
4 1H, 4BH, 0FFH, 30H, 20H, 0A3H, 0A2H, 3FH, 3EH, 3CH, 4DH, 4EH, 
42H, 36H, 43H, 38H, 5 AH, OFFH, 

OFFH, 0FFH, OFFH, OFFH, OFFH, OFFH, OFFH, 7FH, OFFH, OFFH, 
OFFH, 0A4H, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, 0FFH, 0A0H, 
ODH, OFFH, OFFH, 15H, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, 
OFFH, OFFH, OFFH, OFFH, OFFH, 09 , OFFH, OFFH, OFFH, ODH, 
OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, 
20H, 0A3H, 0A2H, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, OFFH, 
0A1H, OFFH, OFFH, OFFH, 

OFFH, OFFH, OFFH, 5FH, OFFH, 7DH, 7BH, 7FH, OFFH, 7EH, 5CH, 
0A4H, 60H, 5EH, 7CH. OFFH, OFFH, OFFH, OFFH, OAOH, ODH, 
1OH.0FH. 15H, 15H. 19H, 14H, 12H.05, 17H, 11H,09,6OH, 
5EH, 7CH, 09 , OFFH, OFFH, OCH, ODH, OAH, 08, 07 , 06 , 04 , 
13H, 0 1 , OBH, OFFH, 7DH, 20H, 0A3H, 0A2H, OFFH, OFFH, OFFH, 
0DH,0EH,92, 16H.03, 18H, 1AH.0FFH, 

39H, 38H, 37H, 2DH. 2BH, 30H, 39H, 7FH, 37H, 36H, 35H, 34H. 
33H, 32H, 3 1H, 38H, 36H, 35H, 34H, OAOH, ODH, 70H, 6FH, 15H, 
75H, 79H, 74H, 72H, 65H, 77H, 7 1H, 69H, 33H, 32H, 3 1H. 09 , 
27H, 3BH, 6CH, ODH, 6AH, 68H, 67H, 66H, 64H, 73H, 6 1H, 6BH, 
OFFH, 30H, 20H. 0A3H, 0A2H, 2FH, 2EH, 2CH, 6DH, 6EH, 62H, 
76H, 63H, 78H, 7AH, OFFH) ; 
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/*    STATUSSBA8E      -    START   OF    STATUS    LINE    AT   EACH   TERM  */ 
/*    DISPLAYSBASE   -    START   OF    DISPLAY   LINES  */ 

DECLARE   STATUSSBASE      DATA 

( 00H, 07H, 40H, 09H, 30H, OBH, 0C0H, ODH)  ; 
DECLARE   DISPLAYS BASE   DATA 

( 40H, 07H, 80H, 09H, OCOH, OBH, 00H, OEH)  ; 

/'*  MTSSMESSAGE    -    DATA   VECTOR  CONTAINING    ALL    THE    MTS    *s 

/*  MESSAGES    WHICH    MAY  BE    DISPLAYED    IN    */ 

/*  TOE   MTS    MSG   FIELD   OF    THE   STATUS            */ 

/*  LINE.                                                                                 */ 

/*  SIZESMESSAGE-    DATA  VECTOR  CONTAINING   THE   TEXT           */ 

/■*■  PORTION   OF   THE   SIZE   MSG  FIELD   OF        */ 

/**  THE    STATUS    LINE.                                                       */ 

DECLARE   MTSSMESSAGE   DATA   (  ' 

DECLARE   SIZESMESSAGE    DATA    (  'K  MTS    ')  ; 

/%        ####**#*;>:#*#*#****   #/ 

/*   THE   NEXT  FOUR  DECLARATIONS   PROVIDE   THE   POINTERS  */ 

/*    UTILIZED   TO   CONTROL   THE    INPUT/OUTPUT   AT  EACH  */ 

/-*    TERMINAL.  *• 

/*   CURSOR   -    SPECIFIES    THE   CURRENT  ADDRESS    WHERE   THE  */ 

/*  CURSOR      IS    TO    BE   DISPLAYED.  */ 

/*   CURRENTSLINE   -    ADDRESS   WHICH   POINTS   TO    INITIAL   BYTE  */ 
/*  OF    CURRENT   USER    INPUT   LINE.    THIS    LINE   HAS      */ 

/*  NOT  YET   RECEIVED   A    'CR'    AND   THUS    IS   NOT   YET*/ 

/*  CONSIDERED   AN    INPUT   BUFFER.  */ 

/#    NEXTSCHAR   -    POINTS    TO    NEXT   CHAR   TO    EE    PROCESSED    FROM*/ 
/*  THE    INPUT   BUFFER.     AN    INPUT    IS    DEFINED    AS    A   #• 

/*  STRING   OF    ASCII    CHARACTERS    (FROM    1    TO   5  12)    */ 

/*  WHICH   HAS    BEEN   TERMINATED   BY  A    'CR'    OR  */ 

/*  'MTSSCMD'    KEY  BY  THE   USER.  */ 

/*   ENDSIBUFF   -    POINTS   TO   BYTE  POSITION    IN    INPUT  BUFFER  #/ 
/*  WHERE    'CR'    OR    'MTSSCMD'    WAS    RECEIVED.  */ 

/r  SfE     5ft     5fC     2fC     5fC     -fC  ?fC     -*s     *ji     5f!     5fC     5fC     5j!     S|C     5fC     JjC     JfC     Jf»     *r»^ 

DECLARE   CURSOR  (  B)  BYTE  INITIAL( 0 , 0 , 0,0, 0 , 0, 0, 0) 

DECLARE   CURRENTSLINE    (8)  BYTE  INITIAL( 0, 0, 0, 0, 0 , 0, 0, O) 

DECLARE   NEXTSCHAR  (8)  BYTE  INITIAL( 0, 0, 0, 0, 0 , 0 , 0, 0) 

DECLARE   ENDSIBUFF  (8)  BYTE  INITIAL( 0, 0 , 0, 0, 0, 0, O, 0) 

/*   CAPITALIZE   -   SET  TO   ONE    IF   TERMINAL    IN  CAP   MODE   */ 

DECLARE    CAPITALIZE    (4)     BYTE    INITIAL    (1,1,1,1); 

/*    TERMSSTATUS  -    CONTAINS    THE   CURRENT  STATUS   OF  */ 

/*  EACH  TERMINAL'S    INPUT  BUFFER,  */ 

/*  EITHER    INPUT   WAITING;  */ 

/*  MTS    CMD    READY;    OR    IBUFF    EMPTY.  */ 

DECLARE   TERMSSTATUS    (4)    BYTE    INITIAL   ( [ IBUFFSEMPTY] , 
[  IBUFFSEMPTY] ,  [  IBUFFSEMPTY] , [ IBUFFSEMPTY] ) ; 

/*    SWAPSPOS    -    FOR  EACH   TERMINAL    THERE    IS    A   ONE    BYTE    */ 
/*  SAVE   AREA   WHICH    IS    USED   DURING  CURSOR  */ 

/*  BLINKING   PROCESSING  */ 

DECLARE   SWAPSPOS    (4)    BYTE    INITIAL    ( [ CURSORSCHAR] , 
[ CURSORSCHAR] ,  [  CURSORSCHAR]  ,  [  CURSORSCHAR] ) ; 

EOF 

/***      TERMINAL      INTERFACE   UTILITY  PROCEDURES      **#****/ 


[MACRO   TRUE  '0FFH'] 

[MACRO   FALSE  '0'  ] 


191 


[  MACRO  SWAPSPOS     ' 1 1FDH' 3 


COMP ARESPTRS :  PROCEDURE ; 

/*  COMPARES  TWO  POINTERS  (2  BYTES  EACH)  TO  DETERMINE*/ 
/*  IF  THEY  ARE  EdUAL.  */ 

/*  INPUT:   DE  -  ADDRESS  OF  FIRST  PTR  */ 

/*  HL  -  ADDRESS  OF  SECOND  PTR  *• 

/*  OUTPUT:   A  -  TRUE  IF  EO.UAL,  FALSE  OTHERWISE.      */ 
/*  CALLED  BY:    KEYSCOMMAND;  READ3TERMINAL;  */ 

/#****#:fc*##***&**#:M;**:|c#****#**^ 
CY=0; 
IF  (A=M(DE) — M(HL))  IZERO  THEN 

A=  [  FALSE] 
ELSE 

DO; 

DE=DE+1;  HL=HL+1; 

IF  (A=M(DE) — M(HL))  !ZERO  THEN 

A=C FALSE] 
ELSE 

A=  C  TRUE]  ; 
END; 
END  COMP  ARESPTRS ; 


CONVERTSNUMBRSTOS ASC 1 1 :  PROCEDURE ; 

/***^**^**********************^*******^C*******5JC******/ 

/■*    CONVERTS  THE  SPECIFIED  NUMBER  TO  A  DISPLAYABLE  W/" 

/*  TWO  DIGIT  DECIMAL  NUMBER  (MAX  VALUE  IS  99) .  */ 

/•*  INPUT:   A  -  NUMBER  TO  BE  CONVERTED.  */ 

/*  OUTPUT:  B  -  LEFT  MOST  DIGIT  TO  BE  DISPLAYED.  */ 

/*  C  -  RIGHT  MOST  DIGIT  TO  BE  DISPLAYED.  */ 

/*  CALLED  BY:   SIZESIISG;  STATUS3MSG;  */ 

B=0;  C=A; 

DO  WHILE  (A:: 10)  PLUS; 

B=  B+  1 ; 

C=( A=C-10) ; 

END; 
C=(A=A+30H)  ; 
B=(A=B+30H)  : 
END  CONVERTSNUMBRSTOS ASC 1 1 ; 


GETS  INDEX:  PROCEDURE; 

/**:K********  *****************************************/ 

/#  USED  TO  GET  THE  INDEX  INTO  AN  ADDRESS  ARRAY  BY  */ 

/*  COMPUTING  THE  OFFSET  FROM  A  GIVEN  BASE  ADDRESS.  */ 

/*  INPUT:   A  -  OFFSET  VALUE  (NORMALLY  THE  TASK  OR  */ 

/*              TERMINAL  NUMBER) .  */ 

/*         HL  -  BASE  ADDRESS  */ 

/*  OUTPUT:  DE-  ARRAY  OFFSET  */ 

/*          HL-  ARRAY  OFFSET  (HL=DE)  */ 

/*           BC-  COMPUTED  OFFSET  */ 

/*  CALLED  BY:   SCROLLSDISPLAY;  UPDATES CURS OR;  */ 

/*              KEYSCOMMAND;  TERMSINPUTSCNTL;  */ 

/*              READSTERMINAL;  WRITESTERMINAL  */ 
/**ifs^****^******:K*********************>f:**************/ 

CY=0;  B=0; 

C=(A=<<A);   /*  SET  ADDRESS  OFFSET  TO  0FFSET*2  */ 

HL=HL+BC;  DE=HL; 

END  GETS  INDEX; 


GETS VALUE:  PROCEDURE; 

/*  GETS  A  2  BYTE  VALUE  FROM  MEMORY.  */ 

/*  INPUT:  DE  -  ADDRESS  OF  2  BYTE  VECTOR;  THE  */ 

/#  CONTENTS  ARE  TO  BE  STORED  IN  THE  */ 

/*  HL  REGISTER.  '*/ 

/*   OUTPUT:  HL  -  CONTENTS  OF  2  BYTE  VECTOR  */ 
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ADDRESS   OF   THE   HIGH  ORDER  BYTE  */ 

SCR0LL3DISPLAY;     UPDATESCURSOR;  */ 

KEYSCOMMAND;    READSTERMINAL;  */ 

WRITESTERMINAL;    GETSDISPLAYSADDR  */ 

J  *.Lt  *Lr  »t*  -I*  *i*  "•£*  »>*  *+*  *fr*  "-J'  *J*  *•  J*  vl"  •  ! '  *l»  *J*  v  '*  -f'  *■!•  *  '»  '>  ,i'  *4>  '-I-'  Si*  Vl*  vt«  v '»  •-(•  vl*  O.J  vi/  .  >,  «J*  -f^  *J*  v>  *1#  •  t»  xi.  v>  \V  v[»  \  >  v>   •  »*  -J^  » V  <£»  «J»  v>  vl»      y 

/  ^  *^  ifi  *^  ^  »^  ^  ^  ^»  «f*  'f*  »*»  >f»  *t*  ^  «t»  *|*  »T*  *o  *t*  ^  *TS  *o  «^  ^  *r*  n^  *T*  *f*  *^  <p  *f*  «^  n*  ^  «^*  ^*  ^  «^  ^  W»  »f*  ^  *r»  *f*  ip  *>*  *r*  *^*f*  1*  -T*  / 

L=(A=M(DE));    DE=DE+1;    H=(A=M(DE)); 
END    GETS VALUE; 


/* 

DE   - 

y* 

CALLED 

BY: 

/* 

STORES VALUE:    PROCEDURE; 

•*   STORE   A   2    BYTE   VALUE    INTO    MEMORY.  */ 

/*    INPUT:    HL   -    VALUE   TO   BE   STORED    INTO   MEMORY  */ 

/*  DE   -   ADDRESS   OF   HIGH  ORDER  BYTE  */ 

/*   CALLED  BY:       UPDATESCURSOR;    KEYSCOMMAND;  */ 

/*  READSTERMINAL;    WRITESTERMINAL;  */ 

y#  GETSDISPLAYSADDR;  *y 

M(DE)  =  (A=H);     DE=DE-1;     M(DE)  =  (A=L); 
END   STORES VALUE; 


MOVESBYTES:    PROCEDURE; 

*/ 

*y 
#y 
#y 
*y 
*y 
*y 

/XXXX#X*#XXXXXXXXX*XXXXXXXX*XXXXX-KX*XXX»*%:XVXX*X*tZX*X;/' 
REPEAT; 


y* 

MOVES    BYTES 

/* 

ANOTHER. 

y* 

INPUT:    BC    - 

y# 

DE   - 

y* 

/* 

HL   - 

/* 

/# 

CALLED    BY: 

OF    DATA   FROM  ONE   MEMORY  LOCATION   TO 

NUMBER   OF    BYTE    TO    BE    MOVED. 
STARTING   MEMORY  ADDRESS    TO   MOVE 
BYTES    TO    (DESTINATION). 
STARTING  MEMORY  ADDRESS   TO   MOVE 
BYTES   FROM   ( SOURCE) . 
SIZESMSGj    MTSSMSG; 


M(DE)  =  (A= 
DE=  DE+  1 ; 
BC=BC-1; 
UNTIL    (A:  :B) 


M(  HL) )  ; 
HL=HL+1; 
A=0; 
ZERO    (A: 


C)    ZERO; 


END   MOVESBYTES; 


SVAPSCURSOR:    PROCEDURE; 

s  y>  •£  »j*  y>  >x»  sb  «i.  *j*  *js  t>  *i>  \u  o»  *i»  *>  v>  y»  Oy  •>■  y*  * ■■  » <jr  «j*  »i*  «j^  *^  *j» *>  v>  •.!#  «ia  y*  Sk  >(»  *~v  ^jj  »V  ^J*  *  j*  *>  ■« !»  •■i'  *v  *if  y;  ■•**  ^  Sk  *•!;  ^  ^  S?  / 

/*   SWAP   THE   SPECIFIED   TERMINAL'S   CURRENT  CURSOR  */ 

y*    POSITION    CHAR   WITH   THE    SWAPSPOS    CHAR.  *y 

/*    INPUT:    A      -    TERMINAL   NUMBER  */ 

/■*                      HL   -    DISPLAY  ADDRESS    OF    CURSOR  POSITION  */ 

/*  CALLED  BY:  BL I NKSCURSORS ;  CHECKSCURSOR;  */ 
y*^**^;*****^****^*^*:K^^;|{****:l;:K*A**^^**:ic:fj*yc^:^^;5!;«**3;^*5Sy 

DE=HL;                           /*   SAVE   DISPLAY   ADDRESS  */ 

B=0;    C=A; 

HL=CSWAF3P09]fBC;             /"*    GET   SWAP    ADDRESS  */ 

B=(A=M(DE));                        /«       SWAP  */ 

M(DE)  =  (  A=M(HL))  ; 

M(HL)  =  (  A=B)  ; 

END   SWAPSCURSOR; 


EOF 

y***^**^cy:*»yi:*>(;*^;*^;^c*^sSc^:*^;**^!:;,,:*^;*5(j*^c:S*>J:**S:***5tt**ifs**5i:^:*y 
y********  TERMINAL  INTERFACE  PRIMITIVES  *#**********y 
y^c*^c^c************:*****:fc*******:f:*******^^:5S**^*:;i***:f:^**y 


[  MACRO 

TRUE 

•OFFH' 

] 

[MACRO 

FALSE 

'9' 

] 

[  MACRO 

BLANK 

'20H' 

] 

[  MACRO 

IBUFFSEMPTY 

'0' 

] 

[MACRO 

DISPLAYSSIZE 

'512' 

] 

C MACRO 

TERMSPORT 

'03FH' 

] 

[MACRO 

CURSORSCHAR 

'05FH' 

] 
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^*****:****:**        INTERNAL    LINKAGE    MACROS       **************/ 


[  INT   TBI 


CTB    :=     1000H] 


[MACRO 

STATUSSBASE 

'[HEX 

TB 

+ 

0106HI 

'  ] 

[MACRO 

DISPLAYSBASE 

'[HEX 

TB 

+ 

0111H] 

'1 

[  MACRO 

CURSOR 

'[HEX 

TB 

+ 

01D5H] 

'  ] 

[  MACRO 

CURRENTSLINE 

'[HEX 

TB 

+ 

OlDDH] 

'  ] 

[MACRO 

NEXTGCHAR 

'[HEX 

TB 

+ 

01E5H] 

'] 

[  MACRO 

ENDS  I BUFF 

'[HEX 

TB 

+ 

01EDH] 

'  ] 

[MACRO 

TERMSSTATUS 

'[HEX 

TB 

+ 

01F9H1 

'  ] 

[MACRO    GETS  INDEX 
[MACRO   GET8VALUE 
[MACRO   STORESVALUE 
[M4CR0   SWAPSCURSOR 


' [ HEX   TB    +  024CH]  '  ] 

'  [HEX   TB    +  G259H]  *] 

'  [  HEX  TB   +  0262H] ' ] 

'  [  HEX  TB   +  027EH] ' ] 


BLANKSBISPLAY:    PROCEDURE; 

/*    PLACES    BLANKS    INTO   THE    INDICATED   AREA   OF    A  */ 

/*   TERMINAL   DISPLAY.  */ 


/"* 

INPUT: 

BC 

/■*■ 

DE 

/* 

HL 

/* 

CALLED 

BY: 

/* 

STARTING    ADDRESS    (RANGE    0    TO    5  11) 
NUMBER   OF    BYTES    TO    SET   TO    BLANK 
BASE   ADDRESS 

KEY3C0MMAND;    SCROLLSDISPLAY; 
CLEARSSTATUSSLINE;    MTSSMSG; 


*/ 
*/ 

HL=HL+BC; 
REPEAT; 

M(  HL)  =  (  A=     [  BLANK]  )  ; 

HL=  HL+  1  ; 

DE=DE-1;     A=0; 
UNTIL    (A::D)    ZERO      (A::E)    ZERO; 
END   BLANKSDISPLAY; 


GETSD I SPLAYS ADDR:    PROCEDURE; 

/  IfC  J;i  ^  2fCsf€2fw4N  -<s  Jji-jl^.s  Jfi-jCf*  5K^jjw£  ^fs  *;^  ^fs  Tfs  *n  t^  ^fC  IfC  ijC  ^fwtw,<  ^^;C^,C;fI^i^^,<^*7C'^  ^^^^K^^'JCIfC  ^^ycift  Jfc/ 

/*   GETS   A   MEMORY  ADDRESS    IN   THE   DISPLAY  BUFFER  USING*/ 
/*   THE   DISPLAY  BUFFER  PTR  AS    OFFSET  FROM  THE   DISPLAY*/ 


/*    BASE    ADDRESS, 
/*    INPUT:       BC    - 
/*  DE   - 

/*   OUTPUT:     HL   - 
/*  BC    - 

/*   CALLED   BY: 
/* 
/* 


TERMINAL    NUMBER   OFFSET.  */ 

ADDRESS    OF    DISPLAY   BUFFER  PTR  */ 
MEMORY  ADDRESS    IN   DISPLAY  BUFFER.         *• 

DISPLAY  PTR  VALUE.  */ 

TERMSINPUTSCNTL;    KEYSCOMMAND;  */ 

BLINKSCURSORS;    READSTERM I N AL ;  *• 

WRITE3TERMINAL;  */ 


DECLARE   PTR(2)    BYTE; 
CALL    [ GETS VALUE] ; 

PTR=HL;  /*   SAVE  DISPLAY  PTR  VALUE  %/ 

DE= (HL=[ DISPLAYSBASE] +BC) ;/*GETSVALUE   PARAMETER  */ 
BC=(HL=PTR);  /*    GET   DISPLAY  PTR  VALUE  */ 

CALL    CGETSVALUE];    /*    GET   DISPLAY  BASE  */ 

HL=HL+BC;  /*   CET  DISPLAY  ADDRESS  */ 

END   GETSD ISPLAYSADDR; 


CHECKSCURSOR:    PROCEDURE; 

/*****:»:  ^:***:.,:*;f::!:*^:K********:C**;«5R**********;R*****^*****/' 
/*  PRIOR  TO  CHANGING  THE  CURRENT  CURSOR  POSITION  OR  */ 
/*  DISPLAYING  A  CHARACTER  AT  THE  CURRENT  CURSOR  POS,*/ 
/*    A  CHECK    IS    ALWAYS    MADE   TO   ENSURE   THAT   THE  */ 

^*  CURRENT  DISPLAY  IS  A  DATA  CHARACTER  AND  NOT  THE  */ 
/*  CURSOR  ITSELF  (I.E.  5FH) .  IF  IT  IS  THE  CURSOR  */ 
/*    A   SWAP    IS    MADE.  */ 

/*    INPUT:    A   -    TERMINAL   NUMBER  */ 

/*   CALLED   BY:    KEYSCOMMAND ;    TERMSINPUTSCNTL;  */ 

/*  WRITES TERMINAL;  */ 
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DECLARE   T   BYTE; 

T=A;    HL=  [  CURSOR]  ; 

CALL    [GETS INDEX]  ; 

CALL   GETSD I SPLAYS ADDR; 

IF    (A=M(HL);    A:  :  [  CURSORSCHAR]  )    ZERO   THEN 

DO; 

A=T; 

CALL    [ SWAPSCURSOR] ; 

END; 
END   CHECKSCURSOR; 


GETOSTATUS3ADDR:     PROCEDURE; 

/*   GETS   THE   BASE   ADDRESS   OF   THE   STATUS   LINE   FOR  THE   */ 

/*    SPECIFIED   TERMINAL.  %/ 

/*    INPUT:       A      -   TERMINAL   NUMBER  */ 

/*   OUTPUT:    HL   -   MEMORY  ADDRESS   OF   FIRST  BYTE    IN  */ 

/*  STATUS   LINE.  */ 

S*    CALLED    BY:  CLEARSSTATUSSLINE;     MTSSMSG;  */ 

/*  SIZE3MSG;     STATUSSM3G;  */ 

HL=[STATUSCBASE] ; 
CALL  [GETS INDEX]  ; 
CALL  [GETS VALUE] ; 
END   GETSSTATUSSADDR; 


GETSTERMSSTATUS :    PROCEDURE; 

/-*  RETRIEVES  THE  TEPJ1INAL  STATU3  FOR  THE  INDICATED  */ 

/*    TERMINAL.     TERMINAL    STATUS    SPECIFIES    WHETHER  */ 

/*    OR   NOT   THERE    IS    AN    INPUT   BUFFER   OR   MTS    COMMAND  */ 

/*    READY  FOR  PROCESSING   FOR  THAT   TERMINAL.  */ 

/*    INPUT:       A   -    TERMINAL   NUMBER  */ 

/*    OUTPUT:    A   -    TERMINAL    STATUS  *• 

/*    CALLED   BY:       KEYSCOMMAND;    TERMINALSSTATUS;  */ 

s*                                    UPDATE3CURSOR;     MONITOR    ( MON    MOD);  *• 

B=0;    C=A; 

HL=  [  TERMSSTATUS]  +BC  ; 

A=M(HL)  ; 

END   GETSTERMSSTATUS; 


SCROLLSDISPLAY:    PROCEDURE; 

/  2f»  ?fi  rfc  *fc  rj*  »y»  *o»  •!»  *i>  »•■*  •<■•  *f^*f^ «+» 3K  *t-  *P  *r»  »r*  *P  *P  'o  ?P  *N  *P  3p  *f-  ^^  nS  *P  w^  *n  ^^  ^^  *P*n  *^  <^«P  *J»  3P  *I*  ?i*  *f>  3p*P  3f*  *t*  *P  3f!  «P  'f1*  / 

/*   SCROLLS   THE   DISPLAY  FOR  THE    INDICATED   TERMINAL.       *• 
/•*    INPUT:       A   -    TERMINAL    NUMBER  *• 

/*    CALLED   BY:       UPDATESCURSOR  */ 

DECLARE   TERM  BYTE; 

DECLARE   P0S(2)    BYTE; 

TERM=  A ;    HL= [ D I SPLAYS BASE] ; 

CALL    [GETS INDEX] ; 

CALL   [GETS VALUE];    DE=HL;    /*DE=DISPLAY  BASE   ADDR  */ 

POS=HL;  /-*    SAVE    DISPLAY   BASE    ADDRESS*/ 

BC=64; 

BC=(HL=HL+BC) ;  /*    BC=DISPLAY  BASE   +    64  */ 

HL=448; 

REPEAT; 

M(DE)  =  (A=M(BO)  ; 

BC=BC+1;    DE=DE+1; 

HL=HL-1;    A=0; 
UNTIL    (A::H)    ZERO      (A::L)    ZERO; 

BC=448;  /%    SETUP   PARAMETERS    FOR  */ 

DE=64;  HL=POS;        /"*   BLANK3DISPLAY  PROC        *S 
CALL    BLANKSDISPLAY; 
END    SCROLLSDISPLAY; 
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SENDSBEEP:  PROCEDURE; 

/*  SENDS  A  BEEP  TO  TEE  INDICATED  TERMINAL.  */ 

/*  THE  FORM  OF  THE  TERMINAL  ALERT  CONTROL  BYTE  IS:   */ 

/#         76543210  */ 

/*       */ 

/*        I A3IC3I A2IC2I Al IC1 I AOICOI  */ 

/*       #/ 

/*  WHERE:  */ 
/*       A(I>  =  1;  GENERATES  AN  ALARM  AT  STATION  I.   */ 

/*       C(I)  =  1;  GENERATES  A  CLICK  AT  STATION  I.    */ 

S*     INPUT:   A  -  TERMINAL  NUMBER  */ 

/*  CALLED  BY:   KEYSCOMMAND;  */ 

H=0;  L=A; 

IF  (A::0)  PLUS   (A:: 4)  MINUS  THEN 

DO  CASE  HL; 

OUT(  C  TERMSPORT] ) = ( A=2) ; 

OUT( [ TERMSPORT] ) = ( A=C) ; 

OUT( C  TERMSPORT] )  =  (  A=  20H) ; 

OUT( [ TERMSPORT] )  =  (  A=  80H)  ; 

END; 
END  SENDSBEEP; 


SENDSCLICK:  PROCEDURE; 

/*  SENDS  A  CLICK  TO  THE  INDICATED  TERMINAL.  SEE  */ 

/*  SENDSBEEP  PROC  FOR  DEFINITION  OF  TERMINAL  ALERT  */ 

/*  CONTROL  BYTE.  %/ 

/%    INPUT:   A  -  TERMINAL  NUMBER  */ 

/*  CALLED  BY:   UFDATESCURSOR  */ 

H=0;  L=A; 

IF  (A::0)  PLUS   (A:: 4)  MINUS  THEN 

DO  CASE  HL; 

OUT( [ TERMSPORT] )  =  (  A= 1 ) ; 

OUT( [ TERMSPORT] ) = ( A=4) ; 

OUT( C  TERMSPORT] )  =  (  A= 10H)  ; 

OUT( [ TERMSPORT] ) = ( A=40H) ; 

END; 
END  SENDSCLICK; 


UPDATE3CURS0R:  PROCEDURE; 

/*  CONTROLS  THE  UPDATING  OF  THE  CURSOR  POSITION.  THE*/ 
/*  PRIMARY  CONCERN  IS  TO  CHECK  FOR  SCROLLING  PRIOR  */ 
/*  TO  UPDATING  THE  CURSOR.  SCROLLING  IS  NOT  ALLOWED  */ 
/*  IF  SCROLLING  WILL  DESTROY  ANY  INPUT  DATA  NOT  YET  */ 
/*  PROCESSED.  */- 

/*  SUBPROCEDURES:  CHECKSSCROLLS LOCKOUT  */ 

UPDATESDISPLAYSPTRS  */ 

TERMINAL  NUMBER  */ 

VALUE  TO  WHICH  CURSOR  POSITION  IS   */ 
TO  BE  SET.  */ 

KEYSCOMMAND;  TERMS INPUTSCNTL;       */ 
/*  WRITE3TERMINAL;  */ 

DECLARE  T  BYTE; 
DECLARE  P0S(2)  BYTE; 

CHECKSSCR0LL8L0CK0UT:  PROCEDURE; 

/*  CHECKS  TO  SEE  IF  THERE  IS  AN  INPUT  BUFFER  */ 
/*  READY.  IF  SO,  CHECKS  TO  SEE  IF  SCROLLING  WILL*/ 
/*  DESTROY  INPUT  BUFFER.  IF  SO,  RETURN  TRUE,  */ 
/*  ELSE  RETURN  FALSE.  */ 

/*  OUTPUT:  A  -  TRUE  IF  SCROLLING  IS  LOCKED  OUT  */ 
/***W^*^:*^^******;fc**:K***********"-(CW*********:i<*>f:***/ 

A=T; 

CALL  GETSTERMSSTATUS ; 


/* 

INPUT:          A 

/* 

HL 

/* 

/* 

CALLED   BY: 
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IF  (A=A-[  IBUFFSEMPTY]  >  !ZERO  THEN 

DO;       /*  CHECK  NEXTSCHAR  PTR  */ 

A=T;  HL=  [  NEXTSCHAR]  ; 

CALL  [ GETS  INDEX] ;/*  GET  NEXTSCHAR  OFFSET*/ 

CALL  [ GETSVALUE] ;  /*  GET  NEXTSCHAR  VALUE*/ 

BC=  -64;  CY=0; 

IF  (HL=HL+BC)  CY  THEN  /*  SCROLL  OK      */ 
A= [ FALSE] 

ELSE         /*   SCROLL  LOCKEDOUT         */ 
A=[TRUE3  ; 

END 
ELSE         /*  NO  INPUT  BUFFER,  SCROLL  OK    */ 

A=C FALSE] ; 
END  CHECKSSCROLLSLOCKOUT; 


UPDATESDISPLAYSPTRS:  PROCEDURE; 

/###*#*******##*;(:*#****#****##*******************/ 
/*  UPDATES  ALL  DISPLAY  PTRS  TO  REFLECT  THE  */ 
/*  SCROLLING  OF  THE  DISPLAY.  USES  SETSPTR  TO  */ 
/*  DECREMENT  AND  STOR£  THE  POINTER  VALUES.  */ 
/*  SUBPROCEDURE:  SETSPTR;  */ 

SETSPTR:  PROCEDURE; 

/^**;);;fc*:fc*;f;***5f;***^:^c***.")c***********«*5fcyc:S:.,::.,:**:i;*/ 
/*  SETS  THE  SPECIFIED  PTR  TO  PTR-64,  AND  */ 
/*  STORES  THE  RESULT.  */ 

/*  INPUT:  DE  -  ADDRESS  OF  PTR  */ 

/*^**«***********:*****>f:*;(;;f:^:***:f::f:*******^c*^***/ 

CALL  [GETSVALUE] ; 

BC=-64;  HL=HL+BC; 

CALL  [ STORES VALUE] ; 

END  SETSPTR; 

/*  START  OF  UPDATESDISPLAYSPTRS  PROCESSING   */ 

/  *^:  *«  *^s  5f:  *  ^  ^s*  *y:^5  :K^:^;***ss*:;f«5K^<*^:*>f:*  ********  **yt*Wi^:/ 

/*  SET  CURSOR  TO  LEFT  MARGIN  OF  8TH  LINE*/ 

/*  ON  DISPLAY.  */ 

A=T;  HL=[  CURSOR]; 
CALL  [GETS  INDEX] ; 
HL=448;  DE=DE+1; 
CALL  [ STORESVALUE] ; 

/*  SET  NEXTSCHAR  =  NEXTSCHAR  -  64        */ 
DE= ( HL= [ NEXTSCHAR] +BC) ; 
CALL  SETSPTR; 

/*  SET  CURRENTSLINE  =  CURRENTSLINE  -  64  */ 
A=T;  HL=  [  CURRENTSLINE]  ; 
CALL  [GETS INDEX] ; 
CALL  SETSPTR; 

/*  SET  ENDS  I BUFF  =  ENDS  I BUFF  -  64        */ 
A=T;  HL=[ENDSIBUFF] ; 
CALL  [GETS  INDEX] ; 
CALL  SETSPTR; 
END  UPDATESDISPLAYSPTRS; 

/*:^:***#*;i!***#*^c*«*:*#.-)cyc**:fe***:*^:*****:f:^*s:5|;*****^:***/ 
/*  START  OF  UPDATESCURSOR  PROCESSING  */ 

/*yc*^:^:(c************************************  ******/ 

T=A;  /*  SAVE  INPUT  TERMINAL  NUMBER  */ 
POS=HL;  /*  SAVE  INPUT  CURSOR  POSITION  */ 
BC=  -[DISPLAYSSIZE] ;  CY=0; 

IF  (HL=HL+BC)  CY  THEN    /*   SCROLLING  REQUIRED   */ 
DO; 

CALL  CHECKSSCROLLSLOCKOUT; 

IF  (A=>>A)  CY  THEN   /*  SCROLLING  LOCKED  OUT  */ 
DO; 
A=T; 
CALL  SENDSCLICK; 
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END 
ELSE  /*   SCROLLING    IS   OK  */ 

DO; 
A=T; 

CALL   SCROLLSDISPLAY; 

CALL  UPDATESDISPLAYSPTRS; 

END; 
END 
ELSE  /*   NO   SCROLLING  REQUIRED;    UPDATE   CURSOR  */ 

DO; 

A=T;    HL=[ CURSOR]; 

CALL  [GETS INDEX];  /*  GET  CURSOR  PTR  ADDR  */ 
HL=POS;  /*  SETUP  [STORESVALUE]  PARAMETERS  */ 
DE=DE+1; 

CALL    [ STORESVALUEJ ;    /*    UPDATE   CURSOR  PTR  */ 

END; 
END   UPDATESCURSOR; 


EOF 

/***##*      TERMINAL   KEY  PROCESSING   PROCEDURES      **#***#*/ 


[MACRO   TRUE 
[  MACRO    FALSE 
[MACRO    BLANK 
[MACRO   CURSORSCHAR 
[MACRO    INPUTS WAITING 
[MACRO   MTSSCMDSREADY 
[MACRO    IBUFFSEMPTY 


•0FFH'] 
'©'  ] 

'  20H'  ] 
'5FH'  ] 
'OFFH' ] 
'OFGH'] 
'0'  ] 


/**********      MTS    KEY  COMMAND   MACROS      *****»*********#/ 


[  MACP.O 
[MACRO 
[MACRO 
[  MACRO 
[  MACRO 
[MACRO 
[MACRO 
[  MACRO 


MTS8CMD 

CR 

CHARSDELETE 

LINES DELETE 

CAPITAL 

CURS0R3LEFT 

CURSORSRIGHT 

CLEARSSCREEN 


•OAOH' ] 
•ODH'  ] 
'07FH'] 
'015H'] 
'0A1H* ] 
'0A2H' ] 
'0A3H'] 
•0A4H' ] 


s  t,  ■»  *i\  7ft  ?f»  Jfi  2r»  7f»  «f»  »t*  *f*  ny  *n  7ft  *ff  *fS  *f*  *K  3fS  iff  *ff  *ff  *ff  ^ft  iff  3ff  *ff  3ff  Sff  5ff  7ft  »ff  Jp  7ft  Bff  W  *T*  ^f*  *ff  *ff  iff  »f*  Tjt  7j»  sff  !ff  *it  3ff  7ft  77*  •■,*  7ft  9ff  f 

/*****       INTERNAL    AND    EXTERNAL   LINKAGE    MACROS       ******#/ 


[  INT  GB   TB] 


[GB    :=    0] 


[TB    :=     1000H] 


[MACRO   TCTSSTATUS 


' [ HEX  GB   +   3E95H] ' ] 


[  M\CRO 

ASCII 

♦[HEX 

TB 

+ 

0003H] 

'  ] 

[  MACRO 

DISPLAYSBASE 

'[HEX 

TB 

+ 

0111H] 

'] 

[MACRO 

CURSOR 

'[HEX 

TB 

+ 

01D5H] 

'  1 

[MACRO 

CURRENTSLINE 

'[HEX 

TB 

+ 

01DDH] 

»] 

I  MACRO 

NEXTSCHAR 

'[HEX 

TB 

+ 

01E5H] 

'  ] 

[MACRO 

ENDS  I BUFF 

'  [HEX 

TB 

+ 

01EDH] 

'  ] 

[MACRO 

CAPITALIZE 

'[HEX 

TB 

+ 

01F5H] 

'] 

[MACRO 

SVAPSPQS 

'[HEX 

TB 

+ 

01FDH] 

'] 

[MACRO   COMPARESPTRS 
[MACRO   GETS  INDEX 
[MACRO   GETS  VALUE 
[MACRO   STORESVALUE 


'[HEX  TB  +  0213H]  '] 
' [ HEX  TB  +  024CH] ' ] 
'[HEX  TB  +  0259H]  '] 
'[HEX  TB   +    0262H]  '  ] 


[MACRO    BLANIC9DISPLAY  '[HEX   TB    +    02A3E3 * ] 

[MACRO   GETSD I SPLAYS ADDR  '[HEX  TB   +    02B7H] ' ] 

[  MACRO   CHECKSCURSOR  '  [  HEX  TB   +    02D0H]  ' ] 

[  MACRO    GETSTERMSSTATUS  '  [  HEX  TB   +    02F9H]  ' ] 
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[MACRO  SENDSBEEP 
[MACRO  UPDATE8CURS0R 


• [ HEX  TB  +  033EH] ' ] 
' [ HEX  TB  +  03C2H] ' ] 


KEYSCOMMAND:  PROCEDURE; 

/*  CHECKS  FOR  A  TERMINAL  KEY  COMM4ND  FOR  EVERY  KEY   */ 
/*  INTERRUPT  RECEIVED. 
/*  KEY  COMMANDS  ARE: 


CMD 


MTS  CMD 


CR 


/# 

/* 

/* 

/■* 

/* 

/* 

/* 

/* 

/# 

/*  CHAR  DELETE 

•-* 

/*  LINE  DELETE 

/« 

/*  CAPTIALIZE 

/* 

/* 

sx 

/* 

/*  CLEAR  SCREEN 

/* 

/*  CURSOR  LEFT 

/* 

/# 

/*  CUROSR  RIGHT 

/* 

/* 

/*  SUBPROCEBURES: 

/* 

/* 

/* 

/* 

/* 

/*    INPUT: 

/* 

/*  OUTPUT: 


A 

C 
A 


KEY 


ERROR  RESET 


RESULT 


NEW  LINE; 
ENTER;  SHIFT 
CR; 


BACK  SPACE 


NEXT  FMAT 


*/ 

*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
#/ 
*•* 


FS 


SENDS  A  COMMAND  TO 
MTS  FOR  PROCESSING. 
TERMINATES  THE 
CURRENT  LINE  AND 
I/O  CTL  M; ESTABLISHES  IT  AS 
THE  CURRENT  INPUT 
BUFFER. 

DELETES  THE  LAST 
CHAR  ENTERED. 
DELETES  THE  CURRENT  */ 
LINE.  */ 

FLIP/FLOP  USED  TO  */ 
SET  OR  CLEAR  THE  */ 
TERMINAL  INPUT  MODE  */ 
TO  UPPER  OR  LOWER  */ 
CASE  LETTERS.  */ 
CLEARS  THE  512  CHAR  */ 
DISPLAY  BUFFER.  */ 
MOVES  CURSOR  POS  */ 
CNE  POSITION  TO  THE  */ 
LEFT.  */ 

MOVES  CURSOR  POS  */ 
ONE  POSITION  TO  THE  */ 
RIGHT.  */ 

ACCEPTS  INPUT;  CHECKSLEFTS MARGIN;  */ 
DELETESCHAR;  CLEARSPTRS;  MTSSCMD;  */ 
TERMINATESCL;  CARRIAGESRETURN;  */ 
CHARSDELETE;  LINESDELETE;  CAPITAL;*/ 
CLEARSSCREEN;  CURSORSLEFT;  */ 

CURSORSRIGHT;  CHECKSCASE;  */ 

TERMINAL  NUMBER  */ 

ASCII  CHAR  RECEIVED  */ 

TRUE  IF  CHAR  =  KEY  COMMAND         */ 


FS   S 


—  > 


/*   CALLED  BY: 


TERMS  I NPUTSCNTL ;  */ 

DECLARE  (CHAR,T)  BYTE; 
DECLARE  RESPONSE  BYTE; 


ACCEPTS  I NPUT:  PROCEDURE ; 

/*  CHECKS  THE  TERMINAL'S  CURRENT  STATUS  TO  */ 
/*  DETERMINE  IF  THIS  NEW  INPUT  BUFFER  SHOULD  BE  */ 
/*  ACCEPTED.  IF  SO,  RETURNS  TRUE,  ELSE  FALSE.  */ 
/*  OUTPUT:  A  -  TRUE  IS  INPUT  CAN  BE  ACCEPTED.  */ 
/*  HL  -  IF  A  IS  TRUE  THEN  HL  CONTAINS    */ 

/*  THE  ADDRESS  OF  TERMSSTATUS.       */ 

A=T;  CALL  [  GETSTERMSSTATUS ] ; 

IF  (A: :[ IBUFFSEMPTYl)  !ZERO  THEN 

DO;  /*  INPUT  BUFFER  HAS  NOT  YET  BEEN     */ 
/^PROCESSED : DO  NOT  ACCEPT  NEW  BUFFER*/ 

A=T;  CALL  [SENDSBEEP]; 

A=[ FALSE] ; 

END 
ELSE 

A=[TRUE] ; 
END  ACCEPTS  INPUT; 


CHECKSLEFTSMARGIN:  PROCEDURE; 
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/*   CHECKS   TO  SEE    IF   CURRENT  LINE    IS   EMPTY.  */ 

/■*    COMPARE5PTRS    RETURNS    THE    APPROFRIATE    TRUE/  #/ 

/*    FALSE    VALUE    IN    THE    A    REGISTER.  */ 

/*    INPUT:    DE   -    ADDRESS   OF    CURSOR  */ 

/*                      BC   -    COMPUTED   OFFSET  OF    TERM   NBR  */ 

/*    OUTPUT:    A   -    RETURNED   TRUE    IF    CURSOR    IS  */ 

/*                                   PRESENTLY  AT   LEFT  MARGIN.  */ 
/***************************  ***  ******************/ 

HL=[CURRENTSLiriE]+BC;^*HL=AI>D    OF    CURRENTLINE*^ 
CALL    [C0MPARE8PTRS] ;  /*    COMPARE  */ 

/*    CURSOR  =    CURRENTSLINE   */ 
END   CHECKSLEFTS MARGIN; 


CLEARSPTR:    PROCEDURE; 

/************************************************/ 

/*  SETS  THE  VALUE  TO  THE  SPECIFIED  DISPLAY      */ 
/*  POINTER  TO  ZERO.  */ 

/*  INPUT:  HL  -  ADDRESS  OF  THE  DISPLAY  PTR        */ 

/************************************************/ 
M(HL)  =  (A=0);  HL=HL+1;  M(HL)=A; 
END  CLEARSPTR; 


DELETESCHAR:  PROCEDURE; 

/  *  *  *  * *  *  *  *  *  *  «  *  *  *  SMfc  #  *  *  *  *  *  *  *  *  *  *  *  #  *  *  *  *  *  *  ******  *  *  *  ****/ 

/*  DECREMENTS  THE  CURRENT  CURSOR  POSITION  AND    */ 

/-*  SETS  NEW  CURSOR  POSITION  DISPLAY  TO  BLANK.     */ 

/*  INPUT:  DE  -  ADDRESS  OF  CURSOR  */ 

/*         BC  -  COMPUTED  OFFSET  OF  TERMINAL  NBR   */ 

/************  ************************************/ 

CALL  [ GETSVALUE] ;        /*   GET  CURSOR       */ 

HL=HL-1;  /*   DECREMENT  CURSOR     */ 

CALL  C  ST0RE3VALUE]  ;  /*  SAVE  NEV  CURSOR  POS   */ 

CALL  C GETSD I SPLAYS ADDR] ;  /*  REPLACE  PRESENT  */ 

M(HL)=(A=  [BLANK]);  /*       CHAR  WITH  BLANK  */ 

END  DELETESCHAR; 

TERMINATESCL:  PROCEDURE; 

/************************************************/ 

/*  TERMINATE  THE  CURRENT  LINE.  THE  SAME  */ 
/*  PROCESSING  IS  DONE  FOR  BOTH  AN  MTS  CMD  AND  */ 
/*  A  CARRIAGE  RETURN  ( CR)  SINCE  EACH  SPECIFIES  */ 
/*  THE  END  OF  INPUT  BY  THE  USER.  */ 

/*****************************«******************/ 

/*  CHECK  CHAR  PRESENTLY  BEING  */ 
/*  DISPLAYED  AT  CURSOR  POSITION  */ 
/*  PRIOR  TO  UPDATING  PTRS.  */ 

A=T;  CALL  [ CHECKSCURSOR] ; 

/*  END  OF  CURRENT  LINE;  UPDATE  */ 
/*  DISPLAY  POINTERS  FOR  NEW  INPUT  */ 
/*  BUFFER  AND  NEW  CURRENT  LINE.  */ 
/*  SET  ENDS  I BUFF= CURRENT  CURSOR  POS  */ 

A=T;  HL=[ENBSIBUFF] ; 

CALL  [CETS INDEX] ; 

HL=[ CURSOR! +BC; 

BC=DE;  DE=HL; 

CALL   I GETSVALUE] ; 

DE=BC+1 ; 

CALL  [ STORES VALUE]  ;  /*  ENDS  I BUFF= CURSOR  */ 
/*  MOVE  CURSOR  TO  BEGINNING  OF  */ 
/*  NEXT  LINE.  HL  CONTAINS  THE  */ 
/*  CURRENT  CURSOR  POSITION.  */ 

BC=64;  HL=HL+BC;/*ADD  64  TO  CURRENT  POS;*/ 

L=(A=L   0C0H);/*THEN  CLEAR  LOWER  6  BITS*/ 

A=T; 

CALL    [ UPDATESCURSOR] ; 

/*    SET   CURRENT   LINE    =    NEW   CURSOR   POS*/ 

A=  T ;    HL=  C  CURRENTSL I NE]  ; 

CALL    [GETS  INDEX]  ; 

HL=[ CURSOR] +BC; 

BC=DE;    DE=HL; 
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CALL  [ GETSVALUE] ; 
DE=BC+1; 

CALL  t STORES VALUE]  ; /*CURRENT3L  I  NE=  CURSOR*/ 
END  TERMINATESCL; 


MTSSCMD:  PROCEDURE; 

/*  CHECK  TO  SEE  IF  THIS  INPUT  CAN  BE  ACCEPTED.  */ 

/*    IF  SO,  SET  TERMSSTATUS  TO  MTSSCMDSREADY  AND  */ 

/*  SET  MCP  BIT  IN  TASK  CONTROL  TABLE  TO  ENSURE  */ 

/*  MCP  IS  CALLED  BY  THE  MONITOR  TO  PROCESS  THIS  */ 

/*  MTS  COMMAND.  */ 

CALL  ACCEPTS  INPUT; 
IF  (A=>>A)  CY  THEN 

DO;  /*    ACCEPT  INPUT  BUFFER       */ 

M( HL) = ( A= [ MTSSCMDSREADY] ) ; 

B=G;  C=(A=T)  ; 

HL=[TCTSSTATUS]    +    BC; 

M(HL)  =  (  A=M(HL)    N    2); 

CALL   TERMINATESCL; 

END; 
END   MTSSCMD; 


CARRIAGESRETURN:  PROCEDURE; 

/*  USER  HAS  TERMINATE  CURRENT  LINE.   CHECK  TO  */ 

/*   SEE  IF  NEW  INPUT  BUFFER  CAN  BE  ACCEPTED.   IF  */ 

/*  SO,  SET  TERMSSTATUS  TO  INFUTSWAITING  AND  */ 

/*  TERMINATE  CURRENT  LINE.  */ 

CALL  4CCEPTS INPUT; 
IF  (A=>>A)  CY  THEN 

DO;  /*   ACCEPT  INPUT  BUFFER      */ 

M( HL) = ( A= [ INPUT3VAITING] ) ; 

CALL  TERMINATESCL; 

END; 
END  CARRIAGESRETURN; 


CHARSDELETE:  PROCEDURE; 

/******^**  ******:!=  ******:S**y!W****:K5K^:***#  ******»***/ 

/*  CHECK  TO  ENSURE  THAT  CURRENT  LINE  IS  NOT  */ 

/*  EMPTY.  THEN  DELETE  THE  PREVIOUSLY  ENTERED  */ 

/*  CHAR.  */ 

/*  INPUT:  DE  -  CURSOR  OFFSET  ADDRESS  */ 

CALL  CHECKSLEFT3 MARGIN; 
IF  (A=>>A)  CY  THEN 

DO;  /*  CURRENT  LINE  EMPTY    */ 

A=T; 

CALL  ISENDSBEEP] ; 

END 
ELSE 

DO;  /#       DELETE  CHAR      */ 

A=T;  CALL  [  CHECKSCURSORJ  ; 

A=T;  HL=[  CURSOR]; 

CALL  [GETS  INDEX]; 

CALL  DELETESCHAR; 

END; 
END  CHARSDELETE; 


LINESDELETE:  PROCEDURE; 

/#**:*###*  ;£:(;*  **#*:?;  #***;(:  :f;3c:::******:J;:R  **  *#**:(:  *#**##:£:£:£/ 
/*  CHECK  TO  ENSURE  THAT  CURRENT  LINE  IS  NOT  */ 
/%  EMPTY.  IF  NOT,  THEN  DELETE  THE  CURRENT  LINE.*/ 
/*  INPUT:  DE  -  CURSOR  ADDRESS  OFFSET  */ 

/**#*;£#  W*#:^:*:fc###^****«*>K****#*#**:R>ft  ******#***#**/ 
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CALL  CHECKSLEFTSMARGIN; 
IF  (A=>>A)  CY  THEN 

DO;  /*  CURRENT  LINE  EMPTY    */ 

A=T; 

CALL  [SEND5BEEP] ; 

END 
ELSE 

DO; 

A=T;  CALL  [  CHECK3CURS0R]  ;  A=0; 

DO  WHILE  (A=>>A)  ICY; 

A=T;  HL=C CURSOR]; 

CALL  [GETS  INDEX];  /*  GET  CURSOR  OFFSET  */ 

CALL  DELETESCHAR; 

A=T;  3L=  [  CURSOR]  ; 

CALL  [GETS  INDEX]  ; 

CALL  CHECKSLEFTSMARGIN; 

END; 

END; 
END  LINES DELETE; 


CAPITAL:  PROCEDURE; 

/*  SET  OR  CLEAR  THIS  TERMINALS  CAPITALIZE  FLAG.  */ 
/  ^  *  *  *  :fc  yz  *  * :,-; :,';  * .-;: :;:  #  :S:f: :.': :;:  *  #  * ;,':  * $ :;-.  *  *  #  *  :fc  $  * :;: ;£  *  :,'t  * :;:  *»  *  $  $ ;(.-  *  ^c*  2:  / 

B=0;  C=(A=T);  HL=[ CAP ITALIZE] +BC; 
M(HL)=  (A=M(HL)  \\1); 
END  CAPITAL; 


CLEARSSCREEN:  PROCEDURE; 

/*    CLEARS  THE  512  BYTE  DISPLAY  BUFFER  AND        */ 
/*  REINITIALIZES  THE  DISPLAY  POINTERS.  */ 

/*  INPUT:  HL  -  CURSOR  ADDRESS  */ 

CALL  CLEARSPTR;      /*  REINITIALIZE  DISPLAY  */ 

A=T;  HL=[CURHENTSLINE] ;/*  PTRS  AND  TERMINAL  */ 

CALL  [GETS  INDEX];  /*  STATUS.        *• 

CALL  CLEARSPTR; 

A=T;  HL= [ NEXTSCHAR] ; 

CALL  [GETS  INDEX]  ; 

CALL  CLEARSPTR; 

A=T;  CALL  [ CETSTERMSSTATUS]  ; 

M(BL)=(A=[  IBUFFSEMPTY])  ; 

/*  CLEAR  THE  DISPLAY         */ 

A=T;  HL=[DISPLAYSBASE] ; 
CALL  [GETS  INDEX]  ; 

CALL  [GETS VALUE];   /*  DISPLAYSBASE  PTR  IN  HL*/ 
BC=0;  DE=5  12;  /*  SETUP  INPUT  PARAMETERS  FOR  */ 
/*  CBLANKSDISPLAY]  PROC        */ 
CALL  [BLANKSDISPLAY] ; 

/*  RESET  SWAPSPOS  TO  CURSORSCHAR        */ 
B=0;  C=(A=T); 
HL=[  SWAPSPOS] +BC; 
M(  HL)  =  (  A=  [  CURSORSCHAR] )  ; 
END  CLEARSSCREEN ; 


CURSORSLEFT:  PROCEDURE; 

/*  MOVES  THE  CURRENT  CURSOR  POSITION  BACK  ONE.  */ 

/*  CHECKS  TO  ENSURE  THAT  CURSOR  IS  NOT  ALREADY  */ 

/*  AT  THE  LEFT  MARGIN  OF  CURRENT  LINE.  */ 

S*    INPUT:  DE  -  CURSOR  ADDRESS  */ 

CALL  CHECKSLEFTSMARGIN; 
IF  (A=>>A)  CY  THEN 

DO;      /*  AT  LEFT  MARGIN;  SEND  BEEP     */ 

A=T; 

CALL  [SENDSBEEP] ; 

END 
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ELSE 

DO;  /*    DECREMENT   CURSOR  */ 

A=T;    CALL    [ CHECKS CURS OR] ; 

A=T;    HL=[  CURSOR]; 

CALL  [GETS  INDEX]  ; 

CALL  [ GETS VALUE]  ; 

HL=HL-1; 

CALL  [ STORESVALUE]  ; 

END; 
END  CURSORSLEFT; 


CURSORSRIGHT:  PROCEDURE; 

•*  MOVE  THE  CURRENT  CURSOR  POSITION  FORWARD  ONE.*/ 
/*  INPUT:  DE  -  CURSOR  ADDRESS  */ 

/#*  **#:•:*#*;;:?;:  *##:**:■:  **************.•»;*:!:**************/ 

A=T;  CALL  [ CHECKSCURSOR] ; 

A=T;  HL=[  CURSOR]  ; 

CALL  [GETS  INDEX]  ; 

CALL  [ GETSVALUE]  ; 

IIL=HL+1;  /*  SETUP  NEW  CURSOR  POS  */ 

A=T;  CALL  [  UPDATESCURSOR]  ; 

END  CURSORSRIGHT; 


CHECKSCASE:  PROCEDURE; 

/**:S****^***:(i***«**:K******^****^**^:K^:S***********/ 

/*  USES  A  CASE  STATEMENT,  INSTEi\D  OF  'ELSE  DO'  *• 

/%   TO  CHECK  FOR  THE  LAST  FOUR  KEY  COMMANDS .   IF  */ 

/*  NOT,  RESPONSE  IS  SET  TO  FALSE.   (NOTE:  CASE  */ 

/-*  STTTT  MUST  BE  USED  TO  GET  AROUND  ML80 '  S  PARSE  */ 

/*  STACK  OVERFLOW,  CAUSED  BY  TOO  MANY  ' IF  THEN  #/ 

/*  ELSE  DO'  STMTS.  */ 

/*  INPUT:  DE  -  CURSOR  ADDRESS  */ 

H=0;  L=( A=CHAR-0A1H) ;  /*  SETUP  CASE  OFFSET   «/ 
IF  (A::0)  PLUS   (A:: 4)  MINUS  THEN 

DO  CASE  HE; 

CALL  CAPITAL; 

CALL  CURSORSLEFT; 

CALL  CURSORSRIGHT; 

DO;  HL=DE;  CALL  CLEARSSCREEN ;  END; 

END 
ELSE 

RESPONSE= ( A= [ FALSE] ) ; 
END   CHECKSCASE; 

/*    START   OF    KEYSCOMMAND    PROCESSING  */ 

T=A;    CHAR=(A=C);    /*      GET    INPUT   PARAMETERS  */ 

RESPONSE=  (  A=  [  TRUE] ) ;  /*    INITIALIZE   RESPONSE      */ 

A=T;    HL=[  CURSOR];  /*    GETS  INDEX  P. ARAMETERS  */ 

CALL    [GETS INDEX];  /*    GET  CURSOR  OFFSET   ADDRESS*/ 

IF    <A=CHAR-[MTSSCMD])    ZERO   THEN  /*    MTS   CMD      */ 

CALL    MTSSCMD; 

ELSE  DO; 

IF  (A=CHAR-[CR] )  ZERO  THEN   /*  CARRIAGE  RETURN   */ 
CALL  CARRIAGES RETURN 

ELSE  DO; 

IF  (A=CHAR-[CHARSDELETE])  ZERO  THEN 

CALL  CHARSDELETE     /*       CHAR  DELETE  CMD  */ 

ELSE  DO; 

IF  (A=CHAR-[LINESDELETE] )  ZERO  THEN 

CALL  LINESDELETE     /*       DELETE  LINE  CMD  */ 
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ELSE 

CALL  CHECKSCASE;     /*  USE  CASE  STMT  TO  */ 

/*  CHECK  FOR  REMAINING  */ 

/*  KEY  COMMANDS.  */ 

END;  END;  END;  /*  END  OF  ELSE  DO'S      */ 

A= RESPONSE; 

END  KEYSCOMMAND; 


TEIinSINrUTSCNTL:  PROCEDURE; 

/#  CONVERTS  THE  INPUT  MATRIX  CODE  TO  ASCII;  CHECKS  */ 

•*  FOR  CAPIALIZATION  AND  CONVERTS  LOUVER  TO  UPPER  *• 

/*  CASE  LETTERS  IF  REQUIRED;  CHECKS  FOR  MTS  KEY  */ 

/*  COMMANDS;  IF  NOT  A  KEY  CMD  THEN  THE  CHAR  IS  */ 

/*  DISPLAY  AT  THE  TERMINAL  AND  CURSOR  INCREMENTED.  */ 

/"*  INPUT:  C  -  MATRIX  CODE  */ 

/*         E  -  TERMINAL  NUMBER  */ 

/*  CALLED  BY:  TERMINALSHLDR  ( INTERRUPT  MOD)  */ 

DECLARE  (CHAR.T)  BYTE; 

T=(A=E);  /*    SAVE  TERMINAL  NUMBER      */ 

/*  CONVERT  MATRIX  CODE  TO  ASCII  *• 
B=0;  HL=[ASCII]+BC; 
CHAR=(  A=M(HL)  )  ; 

/*   CHECK  FOR  CAPITALIZATION  */ 
D=0;  HL=[ CAPITALIZE] +DE; 
IF  (A=M(HL);  A::0)  ?ZERO   (  A=CIIAR-6  1H)  PLUS 

8  (A=CHAR-7EH)  MINUS  THEN  /*  CONVERT  TO      */ 
CHAR=(A=CHAR-20H) ;  /*  UPPER  CASE  LETTER  */ 

/*  CHECK  FOR  ANY  KEY  COMMANDS    */ 
C=(A=CHAR);  A=T; 
CALL,  KEY3COMMAND; 

/*  A  REG  RETURNED  TRUE  IF  KEY  CMD  FOUND  */ 
IF  (A=>>A)  !CY  THEN         /*   DISPLAY  CHAR      #/ 

DO: 

A=T;  CALL  C CHECK3CURS0R] ; 

A=T;  HL=[ CURSOR]; 

CALL    [GETS  INDEX];    /*   GET  CURSOR  OFFSET  */ 

CALL    [ GETSD I SPLAYS ADDR] ; 

M(HL)  =  (  A=CHAR)  ; 

/*  UPDATE  CURSOR  POSITION  BY  ONE.  BC  WAS*/ 
/*  RETURNED  FROM  GETSD I SPLAYS ADDR  SET  */ 
/*   TO   THE   VALUE   OF    CURSOR.  *• 

HL=BC+1; 

A=T;  CALL  [ UPDATESCURSOR] ; 

END; 
END  TERMSINPUTSCNTL; 


EOF 

••**#**   TERMINAL  INTERFACE  SYSTEM  FUNCTIONS   ********/ 


[MACRO  I BUFFS EMPTY  '0'  ] 

[MACRO  MTSSCMDSREADY  'OF0H'  ] 

[MACRO  CR  '0DH*  ] 

[MACRO  LF  'OAH'  ] 


/*****   INTERNAL  AND  EXTERNAL  LINKAGE  MACROS   *******/ 
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[ INT  GB   TB] 
[MACRO   TASK 


[GB    :=    0]       [TB    :=    10O0H 
'M([HEX  GB   +   3E90H] 


[MACRO   MTSSMESSAGE      '[HEX  TB   +    OUCH] 


[MACRO   SIZEOMESSAGE  '[HEX  TB  + 

[MACRO   CURSOR  '[HEX  TB  + 

[MACRO   CURRENTSLINE  '[HEX  TB  + 

[MACRO   NEXTSCHAR  '[HEX  TB  + 

[MACRO    ENDS  I BUFF  '[HEX   TB  + 


[MACRO 
[  MACRO 
[  MACRO 
[  MACRO 
[  MACRO 
[  MACRO 
[  MACRO 


COMPARESPTRS    '  [  HEX  TB   - 
C0NVERT3NUMBRST0SASC I I 


GETS  I NDEX 
GET3VALUE 
STORES VALUE 
MO VES BYTES 
SWAPSCURSOR 


[HEX 
[HEX 
[HEX 
[HEX 
[HEX 


TB 
TB 
TB 
TB 
TB 


01CFH]  ' 
01D5H3  ' 
01DDH]  ' 
01E5H3 ' 
01EDH] ' 

0213H] ' 
[HEX  TB 
024CH] ' 
0259H1  ' 
0262H] ' 
026BH]  ' 
027EH3 ' 


'3 


+  023 1H] '  ] 


[MACRO  BLANKSDISPLAY     '  [  HEX  TB  +  G2A3H3 ' 3 

[  MACRO  CHECK5CURS0R   •   ' [ HEX  TB  +  O2D0H3  ' 3 

[MACRO  GETSD I SPLAYS ADDR  '[HEX  TB  +  02B7H3 ' 3 

[  MACRO  GETSSTATUSSADBR   ' i  HEX  TB  +  02ECH3  • 3 

[  MACRO  GET3TERN3STATUS   '  [  HEX  TB  +  02F9H3  ' 3 

[  MACRO  UPDATESCURSOR     ' [ HEX  TB  +  03C2H3 ' 3 


BLINKSCURSORS:  PROCEDURE; 

/-*  SWAPS  THE  CURRENT  CONTENTS  OF  CURSORC  I )  WITH      */ 
/*    SWAP3P0S( I)  FOR  EACH  TERMINAL  (1  =  0  TO  3).  */ 

/*  CALLED  BY:  TIMERSHDLR  (  INTERRUPT  MOD)  */ 

DECLARE  I  BYTE; 
I=( A=3) ; 
REPEAT; 

HL=  [  CURSOR] ; 

CALL    [GETS  INDEX] ; 

CALL    [ GETSD I SPLAYS ADDR] ; 

A=  I  ;    CALL    [  SWAPSCURSOR]  ; 

I=(A=I-1)  ; 
UNTIL  ( A: : 0)  MINUS? 
END  BLINKSCURSORS; 


CLEARSSTATUSSLINE:  PROCEDURE; 

/*  CLEARS  THE  STATUS  LINE  OF  THE  SPECIFIED  TERMINAL.*/ 

/*    INPUT:   A  -  TERMINAL  NUMBER  */ 

/*  CALLED  BY:   MTSSIPL  (MONITOR  MOD);  */ 

/**               ttUIT      (SERVICE  MOD);  */ 

CALL  [ GETSSTATUSSADDR3 ; 

BC=0;  DE=64;         /*  SETUP  PARAMETERS  FOR  */ 

CALL  [BLANKSDISPLAY3 ;  /*  BLANKSDISPLAY  PROC  */ 
END  CLEARSSTATUSSLINE; 


MTSSMSG:  PROCEDURE; 

/-*  CONTROLS  THE  MTS  MESSAGE  DISPLAY  FIELD  ON  THE  */ 

STATUS  LINE  OF  THE  TERMINAL  SPECIFIED  BY  'TASK'.  *• 

THE  MTS  MESSAGE  FIELD  STARTS  AT  POSITION  48  AND  */ 

UTILIZES  THE  REMAINING  16  BYTES  FOR  MTS  MESSAGES  */ 

( SEE  MTSSMESSAGE  DATA) .  */ 

INPUT:   E  -  MTS  MESSAGE  NUMBER.  */ 

MTS  (SERVICE  MOD);  */ 

MINISDISK  (MONITOR  MOD);  */ 

RECOVER    (MONITOR  MOD);  */ 

3UMPSTASK  (MONITOR  MOD);  */ 


/% 

/% 
/* 

/% 

S*    CALLED  BY: 

/* 

/* 


DECLARE  MSGNO  BYTE; 
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MSGNO=(A=E)  ; 

A=    [  TASK]  ; 

CALL    [ GET8STATUSSADDR] ; 


BC=48; 


/*   MTS    MSG   FIELD   OFFSET  FROM*/ 


/*   STATUS    BASE   ADDRESS 


E=4;  CY=0; 


ZERO; 


A=MSGNO; 
REPEAT; 

A=<<A; 
UNTIL  (E=E-1) 
DE=(HL=HL+BC) ; 
B=0;  C=A; 
HL= [ MTSS MESSAGE] +BC ; 
BC=  16 ;  CALL  t MOVESBYTESI ; 
END  MTSSMSG; 


/*  COMPUTE  OFFSET  INTO  THE 
/*  MTSSHES3AGE  DATA  VECTOR 

/*  SETUP  PARAMETERS  FOR 
/*  CMOVESBYTES]  PROC 


#/ 


*/ 

*/ 


*/ 


/*  DISPLAY  MSG   */ 


SIZESMSG:  PROCEDURE; 

/**************^'"S**************^***********^^**:f:*****/ 

/*  CONTROLS  THE  DISPLAY  OF  THE  CURRENT  MEMORY  SIZE  */ 

/*  ON  TIE  STATUS  LINE  OF  THE  TERMINAL  SPECIFIED  BY  */ 

/*  'TASK*.   THE  SIZE  MESSAGE  STARTS  AT  POSITION  40  */ 

/*  AND  HAS  THE  GENERAL  FORMAT:  */ 

/*       40       47  */ 

/*       */ 

/*        NRK  MTS         E.G.   16K  MTS  */ 

/*       */ 

/*  WHERE  */ 

/*        'NR'  IS  THE  CURRENT  MEMORY  SWAP  SIZE  */ 

/*       ALLOCATED  TO  THAT  TERMINAL  USER.  */ 

/*  THE  RANGE  IS  FROM  O  TO  48K.  THE  INPUT  MEMORY  */ 

/*  SIZE  NUMBER  IS  CONVERTED  TO  ASCII  FOR  DISPLAY.  */ 

/*  INPUT:   A  -  MEMORY  SIZE  */ 

/*  CALLED  BY:   SIZE  (SERVICE  MOD);  */ 

/*              LOGIN  (SERVICE  MOD);  */ 

DECLARE  MEM3SIZE  BYTE; 

MEM3SIZE=A; 

A=     [  TASK]  ; 

CALL    [ GETSSTATUS3ADDR] ; 

BC=40;                                     /*   SIZE   MSG   FIELD   OFFSET  */ 

HL=HL+BC;                               /*    HL= STARTING   ADDRESS    OF  */ 

/*    SIZE   MSG   FIELD   ON   STATUS  */ 

/*    LINE.  */ 

A=MEMSSIZE; 

CALL  [ CONVERTSNUMBRSTOS ASC III; 

K(HL)=(A=B);  HL=HL+1;    /*  DISPLAY  MEMORY  SIZE  */ 

M(HL)=(A=C);  DE=HL+1;    /*  SETUP  PARAMETERS  */ 

HL= [SIZES MESS AGE] ;       /*  FOR  [  MOVES BYTES]  PROC*/ 

BC=6;  CALL  C MOVESBYTES] ; /*  DISPLAY  REST  OF  */ 

/*       SIZE  MESS ACE  */ 

END  SIZESMSG; 


STATUSSMSG:  PROCEDURE; 

/##**##**##***####***:;<#************#*********;*:**#****/ 

/*  CONTROLS  THE  STATUS  DISPLAY,  POSITIONS  0  THRU  39  */ 

/*  OF  THE  TERMINAL  STATUS  LINE.   IT  HAS  THE  */ 

/*  FOLLOWING  GENERAL  FORMAT:  */ 

/*       0                                      39  */ 

/w       */ 

/*       A=N0rB=N0rC=N0rD=NOrE=NOrF=NOrG=NQrH=N0r  */ 

/*       */ 

/*   WHERE  */ 

/*       THE  LETTER  ON  THE  LEFT  OF  THE  EOUAL  SIGN  */ 

/*       SPECIFIES  THE  DRIVE.  */ 

/*       'NO'  IS  THE  DISK  NUMBER  (0-31).  */ 

/*        'r'  IS  AH  OPTIONAL  PARAMETER  WHICH  IS  */ 

/*       DISPLAYED  WHEN  THE  ATTACHED  DISK  IS  A  */ 

/*       RESTRICTED  (r)  READ  ONLY  DISK.  */ 

/*   THE  TERMINAL  IS  SPECIFIED  BY  'TASK'.  */ 

/*  INPUT:  A  -  ASCII  CODE  FOR  RESTRICT  (r),  */ 

/*             OR  BLANK  ( SPACE) .  */ 
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/*  B   -    DRIVE   NUMBER    (MUST   BE   CONVERTED    TO  */ 

/*  A   LETTER   FOR   DISPLAY) .  */ 

/*  C   -    DISK  NUMBER   ( RANCE   0-31;    MUST  BE  */ 

/*  CONVERTED   TO   ASCII    FOR  DISPLAY).  */ 

/*   CALLED   BY:    LOGIN  (SERVICE   NOD);  */ 

/*  ATTACH  (SERVICE   MOD);  */ 

DECLARE    (  RESTRICT, DR I VESLTR, D I SK3NR)    BYTE; 

/*    GET    INPUT  PARAMETERS  */ 

RESTRICT=A;     DRIVESLTR= ( A=B) ;    DISKSNR= ( A=C) ; 
A=    C  TASK] ;    CALL    C GETSSTATUSSADDR]  ; 

/*   COMPUTE   THE   APPROPRIATE   STATUS        */ 

/*   BASE  OFFSET   TO   DETERMINE   WHERE        */ 

/*    TO   DISPLAY  THIS   STATUS    INFO  */ 

C=0;    B=  (A=DRI VESLTR)  ; 
DO    WHILE    (A::0)     TZERO; 
C=( A=C+5) ; 
B=(A=B-1)  ; 
END; 
HL=HL+BG;         /*   SETUP   ADDRESS   FOR  STATUS   MSG.  */ 

/*    DISPLAY  DRIVE   LETTER  */ 

M(HL)  =  (  A=DRIVESLTR+41H)  ; 
HL=HL+1; 

/*    DISPLAY  EQUAL   SIGN  */ 

M(HL)=(A=*=') ; 
HL=HL+1;     A=DISK3NR; 

/*    CONVERT   AND    DISPLAY   DISK  NUMBER      */ 
CALL    C  C0NVERT3NUMBR3T0SASC 113; 
M(HL)  =  (A=B);     HL=HL+1; 
M(HL)  =  (A=C);    HL=HL+1; 

/*    DISPLAY  RESTRICT  OR  BLANK  BYTE        */ 
M(HL)  =  (A=  RESTRICT)  ; 
END   STATUSSMSG; 


TERMINALSSTATUS:    PROCEDURE; 

/*  PROVIDES  THE  INTERFACE  POINT  FOR  OTHER  MTS  SYSTEM*/ 
/*  FUNCTIONS.  RETRIEVES  THE  CURRENT  TERMINAL  STATUS  */ 
/*   FOR  THE   TERMINAL   SPECIFIED   BY    'TASK'.  */ 

/*  OUTPUT:  A  -  SET  TO  THE  TERMINAL  STATUS  (EITHER  */ 
/*  INPUTSWAITING;    MTS3CMDSREADY;    OR  */ 

/*  IBUFFSEMPTY)    BY  GETSTERMS STATUS   PROC.*/ 

/*    CALLED    BY:       WRITESTERMINAL;     MTS(  SERVICE    MOD);  */ 

/*  READSTERMINAL;  */ 

/*  MTSSIPL    (MONITOR   MOD);  */ 

/  *J>»  sir  vl*  ***  "■(*  -l*  ■•>  *i*  'sir  »*>*■!»  *;*  *'*  sir  -L,  sjr  -sir  <  •*  •-■'  »  tr  »>  sir  »  >  •■•'  -Lr  -Li  -  ir  ii/  »*'  » '>  sir  •  [»  sir  \tr  sir  -  '*  vi»  vjv  --  -V  sir  ■sir  sir  •.'*  sir  sir  str  sir  sir  s-Lr  sir  sir  / 
/     rfs  rfs  »[»  ri-s  rf-s  rjs.  *fs  rfs  rfs  Jjs  rfs  rfs  rfs  rfs  rfs  ,-t%  rfs  rfs  »(»  r,s  .f*  *fs  ■■(■»  rfs,  rfs  rfs  rfs  rps  -,  ,  rfs  rfs,  rfs  rfs  rfs  rfs  .j*  rfs  *T»  'C*  'P*  'T'  **»  *T+  *T*  *%'+  *T*  *«  *  *T*  *T*  "v*  If*  <^  /^ 

A=  [  TASK]  ; 

CALL    [ GETSTERMSSTATUS] ; 

END   TERMINALSSTATUS; 


READSTERMINAL:    PROCEDURE; 

/***:!;:(«:£;!::!;:£:<::,'::£:<:*:<:**:£**:!:*******************************/ 
/*  GETS  THE  NEXT  CHAR  FROM  TnE  TERMINAL  INPUT  BUFFER*/ 
/*    SPECIFIED    BY    'TASK'.  */ 

/*    IT    IS    ASSUMED   THAT  THE   CALLING   PROCEDURE   HAS  */ 

/*   CHECKED   TERMINAL   STATUS   TO   ENSURE    INPUT    IS  */ 

/*    WAITING  PRIOR  TO   CALLING  READSTERMINAL.  */ 

/*   A  TEST  FOR  END   OF    IBUFF    IS   MADE   AND    IF   SO,    A  */ 

/*  *CR'  CHAR  IS  RETURNED;  TIIE  TERMINAL  STATUS  IS  SET*/ 
/*  TO  EMPTY;  AND  THE  NEXTSCHAR  PTR  IS  SET  TO  CURRENT*/ 
/*    LINE.  */ 

/*  IF  NOT  AT  END  OF  IBUFF,  THE  NEXT  CHAR  IS  RETURNED*/ 
/*    AND   THE    NEXTSCHAR   PTR    INCREMENTED.  */ 

/*    OUTPUT:    A   -    CHAR  OR  CR  */ 

/*  CALLED  BY:  MTS  (SERVICE  MOD);  MTSSIPL  (MONITOR);*/ 
/*  MONITOR    (MONITOR   MOD) ;  */ 

/^c***s(;;K*^:***W************:S**:*******************  ******/ 

DECLARE   CHAR  BYTE; 

DECLARE   PTR(2)    BYTE; 
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A=    [  TASK]  ;    HL=  [  NEXTSCHAR]  ; 

CALL  [GETS INDEX];  /*  DE=ADDR  OF  NEXTSCHAR  PTR  */ 
HL=[END3IBUFF]+BC;/*  HL=ADDR  OF  ENDS  I BUFF  PTR  */ 
CALL  LCOMPARESPTRS] ;  /*  NEXT3CHAR= ENDS  I BUFF  ??  */ 
IF    (A=>>A)    CY  THEN 

DO;  /'*    AT   END   OF    I  BUFF,    SET  */ 

/*   NEXTSCHAR   =    CURRENTSLINE  */ 

A=    [TASK1;    HL=  [  CURRENTSLINE]  ; 

CALL    [GETS INDEX] ; 

BC= ( HL= [ NEXTSCHAR] +BC)  ; 

CALL    [GETSVALUE];  /#    HL= CURRENTSLINE   VALUE*/ 

DE=BC+1; 

CALL  [ STORESVALUE] ; 

/*    UPDATE  TERMINAL  STATUS        */ 

CALL  TERMINALSSTATUS;    /*  RETURNS  HL=ADDR   */ 

/*   OF  TERH3STATUS .   */ 

M( HL ) = ( A=  [I BUFFSEMPTY] ) ; 

/*    RETURN  'CR'  TO  CALLER      */ 

CHAR=  (  A=  [  CR]  )  ; 

END 
ELSE  /*  NOT  AT  END  OF  I BUFF  #/ 

/*    RETURN  TEE  CHAR  */ 

DO; 

A=  [  TASK]  ;  HL=  [  NEXTSCHAR]  ; 

CALL  [GETS  INDEX];    /*  GET  AND  SAVE  %/ 

FTR=HL;  /*  NEXTSCHAR  OFFSET      */ 

CALL  [  GETSD I  SPLAYS  ADDR]  ; 

CHAR=(A=M(HL)  )  ;      /*   RETURN  CHAR         */ 
/*  INCREMENT  NEIfTSCHAR  */ 

DE= (  HL= PTR+ I )  ;        /*  SETUP  [STORESVALUE]   */ 

HL=  BC+ 1 ;  /*         PARAMETERS  */ 

CALL  [ STORESVALUE] ; 

END; 

A=CHAR;  /*  RETURN  APPROPRIATE  RESPONSE   *• 

END  READSTERMINAL; 


WRITESTERMINAL:  PROCEDURE; 

/#**:£*:£#;«:*****##**»:  *:l::£***#**tt**^ 

S*    DISPLAYS  THE  CHAR  AT  THE  CURRENT  CURSOR  POSITION  *^ 

/*  OF  THE  TERMINAL  SPECIFIED  BY  'TASK'.  IT  CHECKS  *• 

/*  FOR  TWO  SPECIAL  CHARACTERS  WHICH  AFFECT  THE  *• 

/*  DISPLAY  CURSOR  POSITION.  */ 

/*  'CR'  RETURNS  THE  CURSOR  TO  THE  BEGINNING  OF  THE  */ 

/*  CURRENT  DISPLAY  LINE.  'LF'  MOVES  THE  CURSOR  DOWN  */ 

/*  TO  THE  NEXT  LINE.  */ 

/■*    FOR  ALL  OTHER  CHARACTERS,  THE  CHAR  IS  DISPLAYED  */ 

/*    AND  THE  CURSOR  POSITION  INCREMENTED.  *• 

/*  PRIOR  TO  OUTPUT,  THE  CURRENT  CURSOR  DISPLAY  */ 
/*  ADDRESS  IS  CHECKED  TO  ENSURE  THAT  THE  CURSOR  CHAR*/ 

/*  IS  SAVED.   OUTPUT  OF  CHARACTERS  IS  DONE  UNDER  */ 

/*  INTERRUPT  LOCKOUT  TO  ENSURE  THAT  SWAPPING  BY  */ 

/*    BLINKS CURSORS  FROC  IS  NOT  DONE.  */ 

/*  SUBPROCEDURE :  UPDATESPTRS;  */ 

/*  INPUT:   E  -  ASCII  CODE  OF  CHAR  TO  BE  DISPLAYED  */ 

/*  CALLED  BY:   MTS  (SERVICE  MOD);  */ 

/*              MTSSIPL  (MONITOR  HOD);  */ 

DECLARE  CHAR  BYTE; 

DECLARE  SAVESCURSOR  (2)  BYTE; 

UPDATESPTRS :  PROCEDURE ; 

/*  AFTER  THE  DISPLAY  OF  EACH  CHAR  THE  CURRENT  */ 

/*  LINE  PTR  AND  NEXT  CHAR  PTR  ARE  ALWAYS  SET  TO  */ 

/*  NEW  CURSOR  POSITION.   ADDITIONALLY,  THE  */ 

/*  TERMINAL'S  STATUS  IS  SET  TO  IBUFF  EMPTY.  */ 

/«   GET  CURSOR  POSITION  */ 
A=  [  TASK]  ;  HL=  [  CURSOR]  ; 
CALL  [GETS  INDEX] ; 
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/*   SET  CURRENTSL I NE  =  CURSOR  */ 

BC= ( HL=  [  CURRENTSL I NE] +BC) ; 

CALL  [GETS VALUE];    /*   HL=  CURSOR  VALUE     */ 
DE=BC+1; 

CALL  [  STORES VALUE] ;  /*  CURRENTSL I NE= CURSOR  */ 
SAVESCURSOR=  HL ; 

/*  SET  NEXTSCHAR  =  CURSOR        */ 
A=  [  TASK]  ;  HL=  [  NEXTSCHAR]  ; 
CALL  [GETS  INDEX]  ; 
RL=SAVESCURS0R;  DE=DE+1; 
CALL  [ STORES VALUE] ;  /*  NEXTSCHAR= CURSOR     */ 

/*  SET  TERMINAL  STATUS  =  EMPTY  */ 
CALL  TERM I NALS STATUS; 
M(  HL)  =(  A=  [  IBUFFSEMPTY]  )  ; 
END  UPDATESPTRS; 

/*   START  OF  WRITESTERNINAL  PROCESSING       */ 

DISABLE; 

CHAR=(  A=E)  ; 

A=[TASK];  CALL  [  CHECKSCURSOR]  ; 

A=  E  TASK]  ;  HL=  C  CURSOR]  ; 

CALL  [GETS INDEX]  ; 

IF  (A=CHAR-CCR] )  ZERO  THEN 

DO;  /■*  CARRIAGE  RETURN   */ 

CALL  [GETS VALUE];        /*  IIL=  CURSOR         */ 
L=(A=L   OCOH)  ;       /%  GET  LEFT  MARGIN       */ 
END 
ELSE 

DO; 

IF  (A=CHAR-  ELF])  ZERO  THEN 

DO;  /*  LINE  FEED         */ 

CALL  [  GET3VALUE]  ;    S*  HL=  CURSOR         ■*■/ 
BC=64;  HL=HL+BC; 
END 
ELSE  /*  DISPLAY  CHAR      */ 

DO; 

SAVESCURSOR=  HL ; 
CALL  [GETSDISPLAY3ADDR] ; 
M(HL)  =  (A=CHAR>  ; 
DE= ( HL=SAVESCURSOR)  ; 
CALL  [ GETSVALUE] ; 

HL=HL+1;  /-*  INCREMENT  CURSOR      *• 

END; 
END; 

/*  HL  REG  HOLDS  NEW  CURSOR  POSITION      */ 
A=  [  TASK]  ;  CALL  [  UPDATESCURSOR]  ; 
ENABLE; 

/*  UPDATE  OTHER  DISPLAY  PTRS  */ 

CALL  UPDATESPTRS; 
END  VRITESTERMINAL; 


EOF 
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/*##*#    MTS    COMMAND   PROCESSOR   (MCP)  *      #      *      */ 

19FAH: 

MCP:       PROCEDURE; 

/*      MCP    IS    AN    INDEPENDENT  MODULE   OF   THE   MICROCOMPUTER 
TIMESHARED   SYSTEM   (MTS)    DEVELOPED   FOR  THE   NPS 
MICROCOMPUTER  LABORATORY  SYCOR  440    SYSTEM. 
THIS   MODULE    IS   CALLED   BY  THE   MTS   MONITOR  TO 
PROCESS   ANY  SYSTEM  COMMANDS   ENTERED   THROUGH  THE 
TERMINAL    INTERFACE   BY  THE   USER.       MTS   COMMANDS    -ARE 
VALIDATED    BY  MCP    AND    THEN    SENT   TO    MTS    SERVICE 
CALL   CONTROL    MODULE   FOR  FURTHER  PROCESSING. 
MCP    IS    WRITTEN    IN    PLM  FOR  TWO   REASONS: 

(1)  TO   UTILITZE   A  HIGH-LEVEL   LANGUAGE   TO 
FACILITATE  THE   DESIGN  AND   DEBUGGING  TASK 
DURING   THE   DEVELOPMENT  OF   MCP. 

(2)  TO   PROVIDE   A   PLM  PROGRAM  WHICH    ILLUSTRATES 
THE   FUNCTION    CALL   REQUIREMENTS 

FOR  ANY   USER   PROGRAM   TO    INTERFACE    WITH   MTS. 

THERE   ARE   TWO   PRIMARY  DIFFERENCES    BETWEEN   TEE    MCP 
INTERFACE   WITH   MTS    AND   A  USER  PROGRAM/ MTS    INTERFACE. 

(1)  ONE    IS   THE   ENTRY  PORT.       THE   MTS    INTERFACE   PORT 
FOR  USER  PROCRAMS    IS   20O0H.       THE   ENTRY  PORT 
FOR  MCP    IS    1FO0H. 

(2)  THE   OTHER  DIFFERENCE    IS   THAT  USER  PROGRAMS 
DO    NOT    HAVE    TO    BE    CONCERNED    WITH   SAVING 
AND    RESTORING    THE    MTS    MONITOR   STACKPTR. 

MCP    WILL   PROCESS    THE    FOLLOWING   SYSTEM  COMMANDS 
ENTERED   AT  THE   TERMINAL   BY  THE   USER: 

COMMAND  PARAMETERS 

LOGIN  <DISK  NUMBER>  /<  KEY> 

QUIT  NONE 

ATTACH  <  DRIVE   LETTER>    <DISK  NUMBER>    /<  KEY> 

PROTECT  <DISK   NUMBER>  /<  KEY> 

RESTRICT  <DISK  NUMBER>  /<  KEY> 

UNPROTECT  <DISK  NUMBER>  /<  KEY> 

SIZE  < MEMORY  SIZE> 

WHERE 

< DRIVE   LETTER>-    DESIGNATES    A   VIRTUAL   FLOPPY  DISK 

DRIVE   TO   BE   ONE   OF   THE   LETTERS 

A  THRU  H. 
<DISK   NUMBERS    -    SPECIFIES    A   VIRTUAL    FLOPPY   DISK 

NUMBER   FROM  0-31. 
<DISK  NUMBER>    -    SPECIFIES    A   DISK  NUMBER  FROM  0-31. 
/<KEY>  -    SPECIFIES    A   4    CHARACTER  KEY  CODE. 

< MEMORY  SIZE>    -    SPECIFIES   THE   SIZE   OF   THE   USER 

PROGRAM  AREA. 
*/ 

/  vi»*l*  »i»  *(*  »**  •&  «■••  si»  *'»  vJ/  vj>  sV  vt»*i*  \lf  *lf  *J>  *A»  »V  *J*  vL»^»  k>/  sir  -4*  «[>  >.f*  *?»  »V  *£*  "sir  s''  -l*  *»£»  *i*  "•'*  ""£*  *'■*  *>i*  *v*  "•V  <J>  *i*  "•'■*  "•I-*  "'J'  *•*  ••!*  M*  **■*  »>»•»  »t»  vi*     / 
/    »J»  *T*  *T»*I**r*  T*  *r»  »r»  *f+  «T*  *T**T+  «|*  *r»  »T*  *V»  *T*  *r»  *T*  •**  'T*  *T*  »»»  *f»  «T»  •■•  '0"  *t**r*  »r»  •T'  *T»  *T»  *T*  »r»  *T*  *o  *f*  H*  H*  *0  ^*  *T*  *J*  *f*  *r*  *l*  ^^  «|*  *7*  -l>  *t*  *T»  ^»S 


/*       *       *       *       MCP    LITERAL    AND    DATA   DECLARATIONS       *       *       */ 


/****#  MCP    LITERAL   DECLARATIONS      *      *      #      *      *• 

DECLARE 

LIT  LITERALLY    'LITERALLY', 

MTS  LIT    ' 1F00H' ,/*    INTERNAL   MTS    PORT           */ 
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MTSSCMDSREADY 

LIT 

'OF0H' 

INVALID3CMD 

LIT 

•  r 

TRUE 

LIT 

'OFFH' 

FALSE 

LIT 

'0' 

CR 

LIT 

'ODH' 

LF 

LIT 

'0AH' 

TAB 

LIT 

'9' 

MAXSCBUFFSSIZE   LIT  '64* 


READSMTSSCMD 

LIT 

•-1 

ATTACH 

LIT 

'0' 

MTSSMSG 

LIT 

'  1' 

LOGIN 

LIT 

♦2' 

PROTECT 

LIT 

'3' 

QUIT 

LIT 

'4' 

RESTRICT 

LIT 

'5' 

SIZE 

LIT 

'6' 

UNPROTECT 

LIT 

'7' 

TERM I N ALSSTATUS 

LIT 

'8' 

READSTERMINAL 

LIT 

•9' 

WRITE5TERMINAL 

LIT 

'  10 

/*    INTERNAL    UTS    CUD         */ 
/*MTS    SYSTEM  CMD    NUMBERS*/ 


/*   * 


*   MCP  GLOBAL  DECLARATIONS 


*      *  %/ 


DECLARE 

CBUFF  (64)  BYTE, 

CBUFFSLENGTH  BYTE, 

CBUFFSPTR  BYTE; 


/*  CMD  BUFF  FOR  MTS  COMMAND  */ 
/*  NUMBER  OF  CHARS  IN  CBUFF  */ 
/*  PTS  TO  NEXT  CHAR  IN  CBUFF 

TO  BE  PROCESSED  */ 


DECLARE 

CHAR  BYTE,  /*  USED  FOR  CHAR  MANIPULATION     */ 

VALUE  (2)  BYTE,  /*  VECTOR  FOR  CONVERTING  NUMBERS  */ 

PARAMETERS(6)  BYTE;  /^PARAMETERS  FOR  MTS  SYSTEM  CALLS*/ 


/#**#*   MTS  INTERFACE  PROCEDURES   #*#*#/ 

/:fc*********^^***:K*:(;*^**^**********:K********^***********/ 


/***  -4ZXV  :K*  %t  ?£  W  :p*  :fi  *  3C  :*:  *********  ****^c*»:*:*^**^c*^:5(c^W»:?;*:i:«c^**/' 

/*    MTS1-  PROVIDES  MTS  INTERFACE  FOR  FUNCTIONS 
WHICH  DO  NOT  REQUIRE  A  RETURN  VALUE. 
'F'  CONTAINS  THE  MTS  CMD  NUMBER;  'A'  CONTAINS 
THE  PARAMETER  OR  ADDRESS  TO  LIST  OF  PARAMETERS. 
CALLED  BY:  ERRORSMSC;  SENDSMTSSCMD 

*/ 
MTSl:   PROCEDURE  (F,A); 

DECLARE  F  BYTE,  A  ADDRESS; 

GO  TO  MTS; 

END  MTSl; 

/*    MTS2-  PROVIDES  MTS  INTERFACE  FOR  FUNCTIONS 
WHICH  REQUIRE  A  RETURNED  VALUE. 
•F*  AND  'A'  ARE  THE  SAME  AS  IN  MTSl. 
CALLED  BY:  READSCHAR;  SENDS MTSSCMD 
*/ 
MTS2:   PROCEDURE  (F,A)  BYTE; 

DECLARE  F  BYTE,  A    ADDRESS; 
GO  TO  MTS; 
END  MTS2; 


/*   *   *   *   *   :«   riCP  PRIMITIVE  PROCEDURES   *   *   *   */ 
READSCHAR:   PROCEDURE  BYTE; 
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RETURN  MTS2(READ3MT3SCMD,  0) 
END  READ8CHAR; 


CBUFFSNOTSEMPTY:   PROCEDURE  BYTE; 

RETURN  CBUFFSPTR  <  CBUFFSLENGTH; 
END  CBUFFSNOTSEMPTY; 


DEBLANK:   PROCEDURE; 

DO  WHILE  (CBUFFSPTR  <  CBUFFSLENGTH)  AND 
(CBUFF( CBUFFSPTR)  =  '  ' )  OR 
(CBUFF( CBUFFSPTR)  =  TAB); 
CBUFFSPTR  =  CBUFFSPTR  +  1 ; 
END; 
END  DEBLANK; 


ERRORSMSG:   PROCEDURE; 

CALL  MTSHMTS3MSG,  INVALIBSCMD) 
GOTO  FIN  I; 
END  ERRORSMSG; 


/*    FILLSCBUFF  -  CHECK  CURRENT  TERMINAL  STATUS  FOR 
MTS  COMMAND.  IF  NOT,  EXIT;  OTHERWISE  FILL  THE 
COMMAND  BUFFER  WITH  THE  MTS  COMMAND. 
CALLED  BY:  HCP  MAIN  CONTROL 
*/ 
FILLSCBUFF:   PROCEDURE; 

IF  MTS2C  TERMINALSSTATUS , 0) =  MTSSCMDSREADY  TEEN 
DO; 

CBUFFSPTR,  CBUFFSLENGTH  =  0; 
DO  WHILE  (CBUFFSLENGTH  <=  MAXSCBUFFSS IZE)  AND 

(  (  CBUFF(  CBUFFSLENGTH)  :  =READ3CHAR)  OCR)  ; 
CBUFFSLENGTH  =  C3UFFSLENGTH+ 1 ; 
END; 
END; 
END  FILLSCBUFF; 


INITIALIZE:   PROCEDURE; 
DECLARE  I  BYTE; 
DO  1=0  TO  5; 
PARAMETERS  I)  =  OFFH; 

END; 
VALUE(0),  VALUE(l)  =  0; 
END  INITIALIZE; 


*/ 
LETTER:   PROCEDURE  (C)  BYTE; 
DECLARE  C  BYTE; 
RETURN  C  >=  'A'  AND  C  <=  'Z'; 
END  LETTER; 


/*    NUMBER  -  RETURN  TRUE  IF  'C  IS  A  NUMBER. 
CALLED  BY:  GETSNUMBER;  GETSPARAMETERS ; 
ATTACHSCMD;  SIZESCMD 

NUMBER:   PROCEDURE  (C)  BYTE; 
DECLARE  C  BYTE; 

RETURN  C  >  =  ' 0 '  AND  C  <  =  ' 9 '  ; 
END  NUMBER; 


/*    READSCMDSLINE  -  READS  CHAR  FROM  COMMAND  BUFFER; 
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CONVERTS   LETTERS   FROM  LOVER  TO   UPPER  CASE, 

IF    REQUIRED. 

CALLED   BY:    GETSKEY;    GETSNUMBER;    GETS PARAMETERS; 

ATTACHSCMD;    SIZESCMD;    MCP    MAIN   CONTROL 
READSCMDSLINE:       PROCEDURE   BYTE; 
DECLARE   C    BYTE; 

IF    <C:=C3UFF( CBUFFSPTR))    >=    61H  /*   LOVER  CASE   A  */ 

AND  C   <=    7AH  THEN  /*      LOWER  CASE   Z  */ 

C   =    C   AND   5FH;  /*   CONVERT  TO   UPPER  CASE  */ 

CBUFFSPTR   =    CBUFFSPTR+1; 
RETURN    C; 
END   READSCMDSLINE; 


/*        SCANSTOSBLANK  -    SCAN   TO   NEXT  BLANK  OR  TAB  CHAR. 

CALLED   BY:    MCP    MAIN   CONTROL 
*/ 
SCANSTOSBLANK:       PROCEDURE; 

DO   WHILE    ( CBUFFSPTR< CBUFFSLENGTH)    AND 
(  CBUFF(  CBUFFSPTR) <> *     ')    AND 
(CBUFFC CBUFFSPTR) <> TAB) ; 
CBUFFSPTR   =    CBUFFSPTR+1; 
END; 
END   SCANSTOSBLANK; 


y  \i*  «j»  vt»  vv  \ir  si»  *(*  "i**!*  •>!»  iAf  ilr  ~>lf  »i-*  *!*  *l*  *1*  *l*  *J*  »(*  *-L»  *4*  *i*  M*  *J*  Kt*  *T**i*  *i*  *!»  *>i**i*  M*  •J*  *£*  ■4**J*  *J*  *i^  *i*  "4*  *A»  *i*  "J*  *l*^i*  *i*  *i*  *l*  «J*  *J*  *I*   ^ 

/^  *ft  Jf*  ^«f«^  *^  *S  «T»  »T*  "T*  *T*  »r»  «T*  *T»  *n  **■*  *T*  *f»  *J"*  »!■»  *T»  ^»  *T"  •(*  »n  *(>  »<*  •"**  *T*  '*"*  "T»  *v*  *f»  >f»  >N  «f*  <f*  tf*  «^»  *■}%  #f»  *^  r,i  «f*  >rft  «f»  r«>  ^>  *f>  ^J*  ^  ^  f 

/*        SENDSMTSSCMD   -    'CMD'    CONTAINS   THE   MTS   CMD   NUMBER 
AND    'PARAMETER'    CONTAINS    THE   ACTUAL   PARAMETER 
OR   THE    ADDRESS    OF    THE    ACTUAL    PARAMETER   LIST. 
TWO    MTS    SYSTEM   CALLS    ARE    MADE: 

(1)  MTS2    -    PROCESS    SYSTEM  CMD,    WHICH   RETURNS 

A   RESPONSE. 

(2)  MTS1    -    DISPLAY  RESPONSE   AT   USER  TERMINAL. 
%/ 

SENDSMTSSCMD:       PROCEDURE    (  CMD, PARAMETER) ; 
DECLARE   CMD   BYTE,    PARAMETER  ADDRESS; 
CALL    MTS 1 ( MTSSMSG ,    MTS2  (  CMD , PARAMETER) )  ; 
END    SENDSMTSSCMD; 


X  »c»  ^*»o  *t»  *•»  «f*  *f**i*  *f»  *v»  "T*  W"»  «r*  *>x  *T»  *o  n*  «t»  «7"> -""P"  *r»  ^»*f»  *o»  'p*  *r»  *,■•  »/*  *f»*v»  *r*  «^  *T*  »<*  *f*  »f*  *f*  *r*  *r»  »**  *J*  *v»  •«"*  *T»  "T"  *»*  "c*  *0  ^*  *v*  *T»  *!•<»■  ^*  ^ 

/*#*##      UTILITY  PROCEDURES      ***#***/ 


>  nJ>  ->  •  '»  tV  0>  ■«•*  *i*  •!'  sir  v[»  »>  vl>  vl»  V*  ">>  "{'  <4*  ^V  *i^  "-t*  "-L*  ^■-  •"{*  *t*  -i*  't*  »''  "J*  •■ "'  *-I*  *1*  *  I'  »■>*  »f'  ■" ■{*  v'«  »J*  «-i»  *Ar  st'  «J'  ».''  *-t»  ^1*  >£»  »!•  *J*  vl»  «J*  vi»  vi»  »'»     y 

/  ^  •^*,*^^»Ti  #T>  -7»  -S  -,»  *,»  ^fi  ^f.  -,.  *:->  rj>  •;-  j-f*  '<*  *<>  •<>  *!•  ^  *(*  -T*  *N  »•»  *(»•!>  *l»-(*  'S  "T"  »0  *>^  *«%  *r*  ifiS^S^  •?»  '1**^  *^  ^  *^  H>  ^  'P^  ***  »S/ 

/*        CONV'ERTSVALUE   -    CONVERT   ASCII    CODE    IN    'VALUE' 

TO   APPROPRIATE  BINARY  VALUE.       THE   RANGE   OF   VALUES 
TO    BE    CONVERTED    ARE   FROM   0-31. 
CALLED    BY:     GETSNUMBER; 

CONVERTS VALUE:       PROCEDURE    BYTE; 

IF   VALUE(l)     =    0    THEN   /*ONLY  A   SINCLE    DIGIT   TO   CONVERT*/ 

RETURN   VALUE(0)-30H; 
ELSE  /*   TWO   DIGITS   TO   CONVERT  */ 

RETURN    ((VALUE(0)-3OH)*10+(VALUE(  D-30H))  ; 
END   CONVERTS VALUE; 


s   »i» 5^  7f»  -Js  *fl  5f.  ifC  J}*  •■fC  *jC  Jp  -jC ,f, ^fZ  ifz ?5"  •?»  *r»  in  **^  *f*  *f*  *r*  "f*  nC5fC  rj?  ^JC  Jf>  *fC  *fC »f»  «f^  »Jt  ,jZ  TfC^ft  »fC  Jft  ?ft  ?f-» 5fC 3ft  ?ft  5fC 5f» ?f» ?f» 5fC 5ft  ?f»  5ft  f 

/*         GETSKEY  -    GET   THE    < KEY>    PARAMETER,     IF    ENTERED; 

STORE   KEY    IN   THE   PARAMETER  LIST   STARTING   AT    I. 

CALLED   BY:    ATTACHSCMD;    GET8PARAMETERS ; 
*/ 
GETSKEY:       PROCEDURE    (I); 
DECLARE    I    BYTE; 
IF   CBUFFSN0T3EMPTY  THEN        /*NEXT  CHAR  MUST  BE    '/'  */ 

DO; 

IF    (CHAR:=READSCMDSLINE)     =     '/"     THEN 

DO    WHILE    (I<6)     AND    CBUFFSNOTS EMPTY; 
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PARAMETERS ( I )  =  READSCMDSL I NE ; 
1=1+1; 
END; 
ELSE  /*    '/'     IS   USED   TO    INDICATE   */ 

CALL   ERRORSMSG;    /*    < KEY>    AND    IS    REQUIRED.       */ 
END; 
END   GETS KEY; 


/*        GETS NUMBER  -   GET   <DISK  NUMBER>    PARAMETER  AND 
CONVERT    IT  FROM  ASCII    TO   BINARY.    STORE   THE 
RESULT    IN    PARAMETER  LIST   AT    'I*.    UPON   ENTRY, 
'CHAR'    HOLDS   THE   FIRST  DIGIT. 
CALLED   BY:    ATTACHSCMD;    GETS PARAMETERS ; 

GET8NUMBER:       PROCEDURE    (I); 
DECLARE    I    BYTE; 
VALUE(O)     =    CHAR; 
IF    CBUFFSNOTSEMPTY  AND 

NUMBER<  CHAR: = READSCMDSL I NE) 

THEN  /*      TWO    DIGIT   DISK  NUMBER  */ 

VALUE ( 1 )     =    CHAR; 
PARAMETERS(  I)     =    C0NVERT3VALUE; 
END   GETSNUMBER; 


•*         GETSPARAMETERS   -    USED   TO   GET   THE   <DISK  NUMBER> 
AND    <KEY>    PARAMETERS.    GENERATES    ERROR  MSG    IF 
NEXT  CHAR    IS    NOT   A   NUMBER. 
CALLED   BY:    LOGINOCMD;    GET3REQUIRED3PARAMETERS ; 

GETSPARAMETERS:       PROCEDURE; 

IF   NUMBER(CHAR:=READSCMD3LINE)    TEEN 

DO; 

CALL    GETSNUMBER(O) ; 

CALL    DEBLANK; 

CALL   GETSKEY( 1 ) ; 

END; 
ELSE 

CALL   ERRORS MSG; 
END   GETSPARAMETERS ; 


/*        GETSREQUIREDSPARAMETERS   -    GETS   THE   <DISK  NUMBER> 
AND   <KEY>    PARAMETERS   FOR  THOSE   SYSTEM  CMDS   FOR 
WHICH   THESE    PARAMETERS    ARE    REQUIRED    (NOT 
OPTIONAL) .    GENERATES    ERROR   MSG    IF    PARAMETERS 
ARE   NOT  THERE. 
CALLED   BY:PROTECTSCMD;    RESTRICTSCMD;     UNPROTECTSCMD 

*/ 
GETSREGUIREDSPARAMETERS:       PROCEDURE; 

IF    CBUFFSNOTSEMPTY   THEN 

CALL   GETSPARAMETERS; 

ELSE 

CALL   ERRORS MSG; 

END    GETS REQU I REDS PARAMETERS; 


/  it*  *Z*  •>>'  *fr*  -I"  *J*  *V  *  t*  »i»  ■'J"  '  >  *V  */*  *i*  «!*  *>'"  +t?  >t*«X>  >£*  «J»  ^*  *i»  *Jr  «V  v>  »i*  %lr  »•*  ^  »•>  «Jj«  »f*  vV  s[»  »v  •>  *■#  vy->>  vv  «^  »/*  V  *t*  *i*  *A*  "si*  *>■  v>  v£'  ■«i'-  "-Ir  ->■    X 
/  »I»  *f*  *fv  «t»  *r*  *r*  *r*  *v»  *?•  *T*  »v'  *F*  *r»  *v*  ^r*  *t*  *t*  *N  *t">  "T*  *f*  "T*  *|*  *t*  *t*  *t»  •t*  *t*  *t*  "t»  *t'>  •t*  *T«  *t»  •**  *t»  *%*■  »7»  •  N  ^^  *f*  •r»  n*  *f»  •?*  *^  *r»  «t*  »p  *v*  *r*  "T*  *f*  *i»  X 

•**##*      *       SYSTEM  CMD    PROCEDURES      *       *       *       *       */ 


/*         ATTACHSCMD   - 

FORM:       ATTACH  <  DRIVE   LTR>    <DISK  NR>    /<  KEY> 
ALL    THE    PARAMETERS    ARE    OPTIONAL,     HOWEVER 
<KEY>    CAN   NOT   APPEAR   WITHOUT    IT'S    ASSOCIATED 
<DISK  NUMBER> .    WHEN    PARAMETERS    ARE    ENTERED 
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THEY  MUST  BE  IN  THE  ORDER  INDICATED. 
CALLED  BY:  MCP  MAIN  CONTROL 
*/ 
ATTACHSCMD:   PROCEDURE; 

IF  CBUFFSNOTSEMPTY  THEN 
DO; 

CHAR  =  READSCMD3LINE: 

IF   LETTER(CHAR)    THEN  /*   < DRIVE   LETTER>  */ 

DO; 

PARAMETERS(0)=CHAR-41H;/*CONVERT  TO   BINARY*/ 
CALL   DEBLANK; 
IF   CBUFFSN0T3 EMPTY  THEN   /*   MORE   PARAMETERS   */ 

CHAR   =    READ3CMDSLINE; 
END; 
IF    NUMBER< CHAR)    THEN  ^*    <DISK  NUMBER>  */ 

DO; 

CALL   GETSNUMBER( 1 ) ; 
CALL   DEBLANK; 

CALL   GETSKEYC2);  /*      <  KEY>  */ 

CALL   DEBLANK; 
END; 
END; 
IF   CBUFFSNOTSEMPTY  THEN 

CALL   ERRORS MSG; 
ELSE 

CALL   SEND3MTSSCMD( ATTACH, .PARAMETERS) ; 
END   ATTACHSCMD; 


/*    LOGINSCND  - 

FORM:  LOGIN  <DISK  NUMBER>  /<  KEY> 

THE  PARAMETERS  ARE  OPTIONAL  BUT  < KEY>  CAN  NOT 

APPEAR  WITHOUT  <DISK  NUMBER> . 

CALLED  BY:  MCP  MAIN  CONTROL 

LOGINSCMD:   PROCEDURE; 

IF  CBUFFSNOTSEMPTY  THEN 

CALL  GETSPARAMETERS ; 
CALL  SENDSMTSSCMDC  LOGIN, .PARAMETERS) ; 
END  LOGINSCMD; 


/*    PROTECTSCMD  - 

FORM:  PROTECT  <DISK  NUMBER>  /<  KEY> 
THE  PARAMETERS  ARE  REQUIRED. 
CALLED  BY:  MCP  MAIN  CONTROL 

PROTECTSCMD:   PROCEDURE; 

CALL  GETSREQU I RED* PARAMETERS ; 

CALL  SENDS MTSSCMD( PROTECT,  .PARAMETERS); 

END  PROTECTSCMD; 


/*    QUITSCMD  -  FORM:   QUIT 

NO  PARAMETERS. 

CALLED  BY:  MCP  MAIN  CONTROL 
*•* 
QUITSCMD:   PROCEDURE; 

CALL  SENDSMTSSCMD(QUIT,0) ; 
END  QUITSCMD; 


/%    RESTRICTSCMD  - 

FORM:  RESTRICT  <DISK  NUMBER>  /<  KEY> 
THE  PARAMETERS  ARE  REQUIRED. 
CALLED  BY:  MCP  MAIN  CONTROL 

*/ 
RESTRICTSCMD:   PROCEDURE; 
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CALL  GETSREQUIREDSPARAMETERS; 

CALL  SEND8MTSSCMD(  RESTRICT,  .PARAMETERS)  ; 

END  RESTRICT3CMD; 


/%    UNPROTECTSCMD  — 

FORM:  UNPROTECT  <DISK  NUMBER>  /<  KEY> 
THE  PARAMETERS  ARE  REQUIRED. 
CALLED  BY:  NCP  MAIN  CONTROL 

UNPROTECT*CMB :   PROCEDURE: 

CALL  GETSREQUIREDSPARAMETERS; 

CALL  SEND3MTSSCMD(  UNPROTECT,  .  PARAMETERS)  ; 

END  UNPROTECTSCMD ; 


/%    SIZESCMD  - 

FORM:  SIZE  < MEMORY  SIZE> 
THE  PARAMETER  IS  REQUIRED. 
CALLED  BY:  MCP  MAIN  CONTROL 

SIZESCMD:   PROCEDURE; 

IF  CBUFFSHOTSEMPTY  THEN 
DO; 

IF  NUMBER(CHAR:=REABSCMDSLINE)  THEN       

DO;  •*  GET  MEMORY  SIZE  PARAMETER   *• 

CALL  GETSNUMBER(0) ; 

CALL  SENDSMTSSCMD(  SIZE,  PARAMETERS(O) ) ; 
END; 
ELSE  /*  PARAMETER  MUST  BE  NUMBER       *• 

CALL  ERRORSMSG;  /*  SPECIFYING  MEMORY  SIZE   */ 
END; 
ELSE  /*  C3UFF  EMPTY  -  ERROR  */ 

CALL  ERRORSMSG;  /*  PARAMETER  REQUIRED   */ 

END  SIZESCMD; 


/*   *   *   MTS  COMMAND  PROCESSOR  (MCP)  MAIN  CONTROL  *   *• 
/*   *   *   CALLED  BY:   MTS  MONITOR  MODULE  *   */ 


DECLARE  STACK  (20)  ADDRESS, OLDSP  ADDRESS; 

OLDSP  =  STACKPTR;         /*  SAVE  MTS  STACK  POINTER       */ 
STACKPTR  =  . STACK( LENGTH(  STACK) ) ;   /*  SETUP  MCP  STACKPTR  */ 

CALL  INITIALIZE;  /-*  INITIALIZE  DATA  STRUCTURES  */ 

CALL  FILLSCBUFF;  /%  GET  MTS  COMMAND  */ 

CALL  DEBLANK;  /*  SCAN  TO  FIRST  NONBLANK  CHAR  */ 

IF  CBUFF3N0TS EMPTY  THEN   /*  PROCESS  CMD  BUFFER  */ 

DO; 

CHAR  =  READSCMDSLINE;/*  GET  FIRST  LETTER  OF  CMD  */ 

CALL  SCANSTOSBLANK;   /*  SCAN  TO  NEXT  BLANK,  BECAUSE 

ONLY  THE  FIRST  LETTER  IS  USED 

TO  DETERMINE  THE  CMD  */ 

CALL  DEBLANK; 

IF  CHAR  =  'A'  THEN  /*  ATTACH    */ 

CALL  ATTACHSCMD; 
ELSE 

DO; 

IF  CHAR  =  'L'  THEN  /*  LOGIN     */ 

CALL  LOGINSCMD; 
ELSE 

DO; 

IF  CHAR  =  'P*  THEN  /"*  PROTECT   */ 

CALL  PROTECTSCMD; 
ELSE 
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DO; 

IF  CHAR  =  'Q'  THEN         /*  QUIT      */ 

CALL  QUITSCMD; 
ELSE 

DO; 

IF  CHAR  =  'R'  THEN    /*  RESTRICT  */ 

CALL  RESTRICTSCMD; 
ELSE 

DO; 

IF  CHAR='S'  THEN  /*   SIZE     */ 

CALL  SIZESCMD; 
ELSE 
DO; 
IF  CHAR=,U*  THEN/*UNPROTECT^^ 

CALL  UNPROTECTSCKD; 
ELSE 

CALL  ERRORSMSG; 
END; 
END; 
END; 
END; 
END; 
END; 
END; 

FINI: 

STACICPTR  =  OLDSP;  /%    RESTORE  TITS  MONITOR  STACKPTR        */ 

END  riCP; 
EOF 
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